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Abstract: 

Deductive  techniques  are  presented  for  deriving;  programs  systematically  from  given 
specifications.  The  specifications  express  the  purpose  of  the  desired  program  without  giving 
any  hint  of  the  algorithm  to  be  employed.  The  basic  approach  is  to  transform  the 
specifications  repeatedly  according  to  certain  rules,  until  a satisfactory  program  is  produced. 
The  rules  are  guided  by  a number  of  strategic  controls.  These  techniques  have  been 
incorporated  in  a running  program-synthesis  system,  called  DEDALUS. 

Many  of  the  transformation  rules  represent  knowledge  about  the  program’s  subject  domain 
(eg.,  numbers,  lists,  sets);  some  represent  the  meaning  of  the  construcu  of  the  specification 
language  and  the  target  programming  language;  and  a few  rules  represent  basic  programming 
principles.  Two  of  these  principles,  the  conditional- formation  rule  and  the  recursion-formation 
rule,  account  for  the  introduction  of  conditional  expressions  and  of  recursive  calls  into  the 
synthesized  program.  The  termination  of  the  program  is  ensured  as  new  recursive  calls  are 
formed. 

Two  extensions  of  the  recursion-formation  rule  are  discussed:  a procedure-formation  rule, 
which  admits  the  introduction  of  auxilliary  subroutines  in  the  course  of  the  synthesis  process, 
and  a generalization  rule,  which  causes  the  specifications  to  be  altered  to  represent  a more 
general  problem  that  is  nevertheless  easier  to  solve.  Special  techniques  are  introduced  for  the 
formation  of  programs  with  side  effects. 

The  techniques  of  this  paper  are  illustrated  with  a sequence  of  examples  of  increasing 
complexity;  programs  are  constructed  for  list  processing,  numerical  calculation,  and  array 
computation. 

The  methods  of  program  synthesis  can  be  applied  to  various  aspects  of  programming 
methodology  — program  transformation,  data  abstraction,  program  modification,  and  structured 
programming. 

The  DEDALUS  system  accepts  specifications  expressed  In  a high-level  language,  including 
set  notation,  logical  quantification,  and  a rich  vocabulary  drawn  from  a variety  of  subject 
domains.  The  system  attempts  to  transform  the  specifications  into  a recursive,  LISP-like  target 
program  Over  one  hundred  rules  have  been  implemented,  each  expressed  as  a small  program 
in  the  QLISP  language. 
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INTRODUCTION 

In  recent  years  there  has  been  Increasing  activity  in  the  field  of  progran)  verification.  The 
goal  of  these  efforts  Is  to  construct  computer  systems  for  determining  whether  a given  program 
is  correct,  in  the  sense  of  satisfying  given  specifications.  These  attempts  have  met  with 
increasing  success;  while  automatic  proofs  of  the  correctness  of  large  programs  may  be  a long 
way  off.  it  seems  evident  that  the  techniques  being  developed  will  be  useful  in  practice,  to  find 
the  bugs  in  faulty  programs  and  to  give  us  confidence  in  correct  ones. 

The  general  scenario  of  the  verification  system  is  that  a programmer  will  present  his 
completed  computer  program,  along  with  its  specifications  and  associated  documentation,  to  a 
system  which  will  then  prove  or  disprove  iu  correctness.  It  has  been  pointed  out,  most  notably 
by  the  advocates  of  structured  programming,  that  this  is  'putting  the  cart  before  the  horse.” 
Once  we  have  techniques  for  proving  program  correctness,  why  should  we  wait  to  apply  them 
until  after  the  program  is  complete?  Instead,  why  not  ensure  the  correctness  of  the  program 
while  It  is  being  constructed,  thereby  developing  the  program  and  IU  correctness  proof  "hand  in 
hand"? 

The  point  is  particularly  well-taken  when  we  consider  that  program  verification  relies  on 
automatic  theorem-proving  techniques.  These  techniques  embody  principles  of  deductive 
reasoning,  the  same  principles  that  are  applied  by  a programmer  In  constructing  the  program  in 
the  first  place.  Why  not  employ  these  principles  in  an  automatic  synthesis  system,  which  would 
construct  the  program  instead  of  merely  proving  its  correctness?  Granted,  to  construct  a 
program  requires  more  originality  and  creativeness  than  to  prove  lu  correctneu,  but  both  tasks 
require  the  same  kind  of  thinking. 

Structured  programming  itself  made  an  early  contribution  to  the  automatic  synthesis  of 
computer  programs  in  laying  down  principles  for  the  development  of  programs  from  their 
specifications.  These  principles  are  intended  to  serve  as  guidelines  to  be  followed  by  a human 
programmer.  However,  they  are  not  formulated  precisely  enough  to  be  carried  out  by  a 
machine.  Indeed,  the  proponents  of  structured  programming  have  been  most  pessimistic  about 
the  possibility  of  ever  automating  their  techniques;  Dijkstra  hu  gone  so  far  as  to  say  that  we 
shouldn’t  automate  programming  even  If  we  can,  because  we  would  take  away  all  our 
enjoyment  of  the  task. 

Programming  is  a challenging  task,  and  Its  automation  is  a part  of  artificial  intelligence.  A 
system  to  construct  computer  programs  must  have  a broad  range  of  knowledge  about 
programming  languages,  programming  techniques,  and  the  subject  domain  of  the  program  to 
be  constructed.  Furthermore,  it  must  have  the  ability  to  retrieve  the  relevant  components  of  Its 
knowledge  and  to  combine  them  to  perform  the  task  at  hand.  Programming  is  among  the  most 
demanding  human  activities,  and  Is  among  the  last  tasks  computers  will  do  well.  NeverthelcM, 
the  intrinsic  interest  and  practical  importance  of  the  programming  tuk  have  motivated  many 
researchers  to  consider  the  possibility  of  automating  it. 
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Several  years  ago,  we  began  our  research  on  automatic  program  synthesis  by  considering  a 
large  number  of  simple  programming  tasks.  In  examining  the  derivations  of  programs  to 
achieve  these  tasks,  we  observed  certain  regularities,  steps  that  are  performed  over  and  over 
again  in  a variety  of  subject  domains,  and  that  therefore  can  be  regarded  u representing  basic 
programming  principles.  We  have  specified  these  principles  precisely,  and  have  applied  them 
to  the  construction  of  less  trivial  programs. 

In  this  paper,  we  present  some  of  the  basic  principles  to  be  incorporated  into  an  automatic 
program-synthesis  system.  Such  a system  accepts  specifications  that  express  the  purpose  of  the 
program  to  be  constructed,  without  giving  any  hint  of  the  algorithm  to  be  employed.  With  no 
further  human  intervention,  the  system  attempts  to  transform  these  specifications  into  a 
program  that  achieves  the  expressed  purpose.  This  program  is  guaranteed  to  be  correct  and 
will  always  terminate;  for  the  most  part,  we  will  not  be  concerned  with  its  efficiency. 

The  specifications  are  expressed  in  a sptcification  langtiagt  rich  with  constructs  from  the 
subject  domain  of  the  application.  Because  the  specification  language  does  not  need  to  be 
executed,  it  can  afford  high-level  constructs  close  to  our  way  of  thinking  about  the  subject. 
Specifications  represented  in  such  a language  are  likely  to  be  easy  to  formulate  and  to 
correspond  correctly  to  our  intentions.  The  details  of  the  particular  target  language— the 
language  in  which  the  program  is  to  be  constructed~are  not  important.  In  our  examples,  we 
employ  a simple  LISP-like  language. 

Our  basic  approach  is  to  transform  the  specifications  repeatedly  according  to  certain 
transformation  rules.  Guided  by  a number  of  strategic  controls,  these  rules  attempt  to  produce 
an  equivalent  description  composed  entirely  of  constructs  from  the  target  language.  Many  of 
the  transformation  rules  represent  knowledge  about  the  program's  subject  domain;  some 
explicate  the  constructs  of  the  specification  and  target  languages;  and  a few  rules  represent  basic 
programming  principles. 

Some  of  these  techniques  have  been  incorporated  into  an  experintental  program-synthesis 
system  called  DEDALUS  (the  DEDuctive  ALgorithm  Ur-Synthesizer).  The  purpose  of  this 
system  is  not  to  be  applied  In  practice  but  rather  to  test  our  program>synthesis  ideas.  Most  of 
the  examples  Included  in  this  paper  have  been  carried  out  by  the  DEDALUS  system. 
However,  the  emphasis  of  the  paper  is  not  on  the  details  of  the  DEDALUS  implementation, 
but  on  the  basic  programming  principles  it  incorporates,  which  can  be  applied  in  any  system. 

In  the  past  few  years,  there  have  appeared  several  varieties  of  programming  methodology, 
e g.,  structured  programming,  program  transformation,  and  data  abstraction.  These  disciplines 
recommend  systematic  approaches  to  program  construction  for  making  the  programming  process 
simpler  and  more  reliable.  The  techniques  of  program  synthesis  serve  to  facilitate  the 
application  of  each  of  these  disciplines.  In  this  way,  program-synthesis  research  can  be  of 
value  long  before  its  ultimate  goal  is  achieved. 
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In  this  paper,  we  present  the  basic  concepts  and  principles  of  program  synthesis,  we  extend 
these  methods  to  allow  the  synthesis  of  programs  with  side  effects,  and  we  apply  these 
techniques  to  various  aspects  of  programming  methodology.  Historical  remarks,  comparisons 
with  other  approaches  to  automatic  programming,  and  notes  on  the  DEDALUS  implementation 
are  reserved  for  a final  section. 
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1.  CONCEPTS 


A.  Specifications 

The  first  requirement  of  a specification  language  is  that  it  should  allow  us  to  express  the 
purpose  of  the  desired  program  directly.  In  other  words,  once  we  have  formed  a precise  idea  of 
what  the  program  is  intended  to  do,  we  should  be  able  to  formulate  the  specifications 
immediately,  without  paraphrase.  Furthermore,  it  should  be  easy  for  the  programmer  and 
other  people  to  read  and  understand  the  specifications  and  to  see  that  they  are  correct. 

For  this  reason,  it  is  necessary  that  the  specification  language  contain  very  high-level 
constructs,  which  correspond  to  the  concepts  we  use  in  thinking  about  the  problem  and  which 
are  endemic  to  the  subject  domain  of  the  target  program.  Such  constructs  are  typically  not 
included  In  a conventional  programming  language,  because  it  may  be  impossible  to  find  a 
uniform  way  of  computing  them  or  because  they  may  not  be  amenable  to  efficient 
implementation. 

Because  a specification  language  should  have  a large  number  of  constructs,  and  because 
these  constructs  are  particular  to  the  subject  domain,  we  do  not  attempt  to  define  a complete 
specification  language.  Instead,  we  present  the  specifications  of  some  of  the  programs  we  will 
use  as  examples  later  in  this  paper,  to  illustrate  some  of  the  most  useful  constructs. 

Suppose  we  want  to  construct  a program,  called  tessall,  to  test  whether  a given  number  x is 
less  than  every  member  of  a given  list  I of  numbers,  and  to  output  true  or  false  accordingly. 
This  program  can  be  described  as 

lessalUx  1)  compute  x < all{l) 

where  x is  a number  and 

/ is  a list  of  numbers  . 

Here,  the  expression  x < all{,l)  denotes  the  condition  that  x is  less  than  every  member  of  the  list 
/;  its  value  is  true  or  false  depending  on  whether  or  not  the  condition  holds.  The  expression 
compute  ...  is  the  output  specification,  it  provides  a description  of  the  output  the  target 
program  it  intended  to  produce.  The  expression  where  ...  it  the  Input  specification-,  it  gives 
the  conditions  the  Inputs  x and  I can  be  expected  to  satisfy. 

To  specify  a program  maxlist  to  compute  the  largest  element  of  a given  list  /,  we  write 

maxlistU)  <•■  compute  some  z-.zcl  and  z 2 all(l) 
where  / is  a nonempty  list  of  numbers 

Here,  the  construct  'some  z * P(z)'  denotes  any  element  z satisfying  the  condition  P{z),  and  u < v 
means  that  u is  a member  of  the  list  (or  set)  v. 
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Another  example:  the  greatest  common  divisor  (gcrf)  of  two  nonnegative  integers  is  the 
largest  integer  that  divides  both  of  them.  To  specify  a program  to  compute  the  gcd  of  x and  y, 
we  write 

gcd(x  y)  <--  compute  max{z  : z|x  and  zjy) 

where  x and  y are  nonnegative  integers  and 
X K 0 or  e 0 . 

Here,  max  S is  the  largest  element  of  the  set  S.  The  input  condition  x e 0 or  j e 0 is  included 
because  if  both  x and  y are  zero,  then  any  integer  divides  each  of  them,  and  the  set  of  all  their 
common  divisors  is  infinite  and  has  no  largest  element. 

The  Cartesian  product  cart  of  two  sets  s and  t is  the  set  of  all  pairs  whose  first  element 
belongs  to  s and  whose  second  element  belongs  to  f;  a program  to  compute  it  is  specified  by 

cards  0 <--  computo  {(xy) : x t s and  y*t} 
where  s and  t are  finite  sets. 

Here,  (x  y)  denotes  the  pair  whose  elements  are  x and  y . 


B.  The  Target  Language 

The  techniques  we  employ  in  this  paper  are  not  dependent  on  the  particular  choice  of  a 
target  language,  the  language  in  which  the  desired  program  is  to  be  expressed.  However,  for 
the  sake  of  definiteness,  we  will  represent  the  target  programs  In  this  paper  in  a fixed,  LISP- 
like  language,  which  should  be  readily  understandable. 

For  numbers,  the  target  language  includes  such  familiar  operations  as  x + y,  x - y,  x iy, 
etc.  For  lists,  we  assume  that  the  target  language  contains  the  usual  LISP  primitives: 

head{l) : the  first  element  of  the  nonempty  list  I 

taild) : the  list  of  ail  but  the  first  element  of  the  nonempty  list  I 

consix  1) : the  list  formed  by  inserting  the  element  x at  the  beginning  of  the  list  I . 

Furthermore,  we  include  the  common  conditional  expression: 

if  P then  X else  y . x If  P is  true, 
y if  P is  false. 
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Finally,  we  employ  recursion,  for  example,  a program /tO  may  be  defined  in  terms  of  a recursive 
call  J{tailU)) 

Of  course,  we  can  use  an;'  of  the  target-language  constructs  in  formulating  the  specifications. 
Thus,  the  target-language  may  be  considered  to  be  a subset  of  the  specification  language. 

A segment  of  a program  description  that  consists  entirely  of  target-language  constructs  will 
be  called  a primitive  segment. 

At  times  we  will  choose  to  add  new  primifives  to  the  target  language.  Thus,  if  we  want  to 
write  a program  in  a new  subject  domain,  we  will  add  the  primitives  appropriate  to  that 
domain.  If  we  want  to  express  a program  in  terms  of  some  given  set  of  procedures,  we  will 
treat  those  procedures  as  primitives.  In  the  section  on  side  effects  (Section  4),  we  will  include 
constructs  such  as  assignment  statements  and  arrays  in  the  target  language. 

By  the  same  token,  for  certain  tasks  we  may  choose  to  delete  primitives  from  the  target 
language.  For  instance,  to  construct  a more  efficient  program  we  may  delete  certain  time- 
consuming  primitives.  The  DEDALUS  system  allows  the  user  to  add  or  delete  constructs  from 
its  primitive  set  for  a particular  task. 


C.  Transformation  Rules 

Our  basic  approach  to  program  synthesis  is  to  employ  a large  number  of  transformation 
rules,  which  replace  one  segment  of  a program  description  by  another,  equivalent  description. 
The  task  of  program  synthesis  is  then  reduced  to  applying  these  rules  to  the  given  specification 
repeatedly  until  a primitive  program  is  produced. 

Some  transformation  rules  express  the  principles  of  the  underlying  semantic  domain  (e  g.,  the 
properties  of  the  integers  or  list  structures).  Other  rules  express  the  meaning  of  the  constructs 
in  the  specification  and  the  target  languages  (e.g.,  {u  : P(u)}  in  the  specification  language  and 
fieadU)  in  the  target  language).  Still  others  represent  a formulation  of  buic  programming 
techniques,  which  do  not  depend  on  a particular  subject  domain  (eg.,  the  introduction  of 
conditional  expressions  and  recursion). 

We  use  the  notation 

r ->  r' 

to  denote  a transformation  rule  that  an  expression  of  form  l may  be  replaced  by  the 
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corresponding  expression  t' . The  transformation  may  be  applied  to  any  tubexpressKm  f of  the 
current  program  description.  It  is  not  to  be  applied  in  the  reverie  dtrv..ion  unleu  another  rule 
of  form  t'  ->  t is  given  explicitly. 

For  example,  the  rule 

true  and  Q ->  Q 

means  that  any  expression  of  form  true  and  Q may  be  replaced  by  Q By  applying  this  rule,  we 
may  replace  a program  description 

max{z  : true  and  zjy}  . 

by  the  description 

max{z  : /jy}  . 


A rule 


t ->  t'  if  P 

denotes  that  the  transformation  t •>  t'  can  be  applied  only  if  the  condition  P is  true.  Thus  the 
rule 


u|t;  ->  true  if  u is  an  integer  and  t;  - 0 

denotes  that  a program  segment  u|t;  can  be  replaced  by  true  if  u is  known  to  be  an  integer  and 
V to  be  zero  whenever  the  segment  is  executed.  Thus,  this  rule  can  be  applied  to  transform  a 
program  description 

if  y.O 
then  x\y 
else  . . . 


into 


ifyO 
then  true 
else  .... 

where  x is  known  to  be  an  integer. 

Often,  more  than  one  rule  can  be  applied  to  the  same  program  description  or  even  to  the 
same  segment.  For  example,  the  logical  rule 
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P and  Q ->  Q and  /*’ 
and  the  numerical  rule 

u|n  and  uhu  •>  ujv  and  ujw-v  if  u , v , and  w are  integers 
can  both  be  applied  to  the  program  description 
max{x  : r|*  and  z()i}  . 

In  such  cases  it  must  be  decided  which  rule  is  best  to  apply.  This  difficult  problem  must  be 
faced  in  any  transformation-rule  system.  We  prefer  to  postpone  such  considerations  until  after 
we  have  presented  some  concrete  examples.  (See  Section  2D  on  "Strategic  Controls.') 


D.  Derivation  Trees 

In  applying  a transformation  rule  to  a given  program  description,  we  obtain  a new  program 
description,  which  we  regard  as  a subgoal  of  the  first.  To  this  subgoal  we  apply  additional 
transformation  rules  repeatedly,  until  a primitive  program  description  is  obtained.  This 
description  is  the  desired  program. 

The  top-level  goal  is  obtained  directly  from  the  program’s  specifications.  Thus,  if  the 
program  / is  specified  by 

/(x)  <--  compute  P(x) 
where  Q(,x) , 

the  top-level  goal  will  be 

Goal:  compute  P(x) . 

(Here,  Q(x)  is  a condition  but  P{x)  may  be  any  expression  in  the  specification  language.)  For 
example,  in  deriving  the  ged  program,  we  are  given  the  specifications 

gedix  y)  <•"  compute  max[z  : ztx  and  z|y} 

where  x and  y arc  nonnegative  integers  and 
X 0 0 or  y I*  0 . 


'Actually,  the  DEOALUS  system  does  not  use  this  rule  explicitlyi  the  same 
effect  is  achieved  by  a different  nechanism.  See  "Implementation," 
Section  68. 
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Our  top-level  goal  is  thus 

Goal  1 : compute  max{z  : z|x  and  z|)i} . 

By  applying  the  transformation  rule 
P and  Q «>  Q and  P , 

we  obtain 


Goal  2:  compute  max\z  : z|y  and  z\x]  . 

If  a transformation  rule  imposes  a condition  P,  which  must  be  true  if  the  rule  is  to  be 
applied,  a subgoal  of  the  form 

Goal:  prove  P 

must  be  achieved  before  the  rule  can  be  applied.  For  example,  In  developing  the  program 
lessall{x  1)  to  test  if  a number  is  less  than  every  element  of  a list  of  numbers,  we  begin  with  the 
top-level  goal 

Goal  1 : compute  x < allQ) . 

In  attempting  to  apply  the  rule 

P{all{i))  ->  true  if  I is  the  empty  list, 

which  states  that  any  property  P holds  for  every  element  of  the  empty  list,  we  generate  the 
subgoal 


Goal  2:  prove  / is  the  empty  list . 

To  accomplish  such  a task,  we  must  apply  transformation  rules  repeatedly  to  the  expression  to 
be  proved,  until  the  expression  true  is  produced.  If,  instead,  false  is  produced,  or  If  we 
encounter  a situation  in  which  no  rule  can  be  applied,  the  goal  of  proving  P is  aborted,  and 
the  attempt  to  use  the  rule  that  imposed  as  a condition  is  abandoned. 

If  no  rule  applies  to  a given  subgoal,  backtracking  occurs;  we  seek  alternate  rules  to  apply  to 
jrevious  subgoals.  Backtracking  will  be  discussed  further  in  the  section  on  “Strategic  Controls" 
(Section  2D) 

By  the  process  we  have  just  outlined,  a tree  of  goals  and  subgoals  is  generated.  We  will  call 
this  structure  a program  derivation  tree. 
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2.  ELEMENTARY  PROGRAMMING  PRINCIPLES 

A.  The  Formation  of  Conditional  Expressions 

To  illustrate  the  formation  of  conditional  expressions  and  recursive  calls,  we  exploit  a single 
simple  example  The  program  to  be  constructed,  lts$all(x  /),  is  intended  to  test  whether  a given 
number  x is  less  than  every  member  of  a given  list  I of  numbers,  and  to  output  true  or  foist 
accordingly.  The  specifications,  as  indicated  in  Section  lA,  can  be  expressed  as 

UssalUx  /)  <--  compute  x < all{l) 

where  x is  a number  and 

I IS  a list  of  numbers . 

Note  that  the  output  description  uses  the  all  specification  construct,  which  is  not  primitive; 
therefore,  we  attempt  to  apply  transformation  rules  to  paraphrase  the  output  description  using 
only  primitive  constructs  of  the  target  language. 

We  assume  we  have  at  our  disposal  two  rules  that  explicate  the  all  construct; 

• The  vacuous  rule 

P(alHl))  ->  true  if  I is  the  empty  list 
says  that  any  property  is  true  of  every  element  of  the  empty  list. 

• The  decomposition  rule 

P{all(l))  ->  P(fieadU))  and  P(alHtail(l)))  if  / is  a nonempty  list 

states  that  a property  holds  for  every  element  of  a nonempty  list  if  it  holds  for  the  first  element 
and  for  all  the  rest 

Our  top-level  goal  is  formed  directly  from  the  program’s  specifications: 

Goal  1 1 compute  x < all{l) . 

In  this  discussion  we  will  not  consider  how  to  select  the  rule  to  be  applied;  we  will  auume  for 
the  time  being  that  the  appropriate  rule  magically  appears  when  it  is  relevant. 

One  transformation  rule  that  applies  to  the  current  output  description  is  the  vacuous  rule, 

P(alHl))  ->  true  if  I is  the  empty  list . 
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This  rule  would  allow  us  to  reduce  our  output  description  to  true  if  only  we  could  achieve  the 
subgoal 


Goal  2:  prove  / is  the  empty  list  . 

Of  course,  we  cannot  prove  or  disprove  this  condition.  I is  an  input  that  is  known  to  be  a 
list,  but  that  may  or  may  not  be  empty.  This  is  an  occasion  for  applying  the  conditional- 

foir^ation  rule. 


Conditional  expressions  are  introduced  into  programs  as  a result  of 
hypothetical  reasoning  during  the  program-formation  process.  If  we  fail  to 
prove  or  disprove  a subgoal  of  the  form 

prove  P , 

the  conditional-formation  rule  allows  us  to  introduce  a case  analysis  and 
consider  separately  the  case  in  which  P is  true  and  P is  false.  Suppose  we 
succeed  in  constructing  a program  segment  S|  that  solves  our  problem  under 
the  assumption  that  P is  true,  and  another  segment  S2  that  solves  the 
problem  under  the  assumption  that  P Is  false.  Then  we  combine  the  two 
segments  into  a conditional  expression 

if  P then  S|  else  , 

which  solves  the  problem  regardless  of  whether  P is  true  or  false.  Note  that 
to  ensure  that  this  expression  is  primitive,  we  apply  the  conditional- 
formation  rule  only  when  P itself  is  a primitive  logical  statement. 

L''t  us  return  to  our  example.  Having  failed  to  prove  Coal  2,  that  I is  empty,  we  attempt  to 
ronsfruct  a program  segment  that  will  solve  our  problem  under  the  assumption  that  I is  empty. 

Case  I IS  empty;  in  this  case,  we  are  Justified  in  applying  the  vacuous  rule 

P(allU))  true  if  I is  the  empty  list, 

to  Coal  I,  compute  x < atlU),  yielding  the  primitive  program  segment  true.  This  segment 
solves  our  problem  in  this  case. 

We  have  yet  to  consider  the  case  in  which  / is  nonempty.  This  requires  the  formation  of  a 
recursive  call,  which  will  be  diKussed  in  the  next  section.  However,  at  this  point,  we  know  that 
the  program  will  have  the  form 
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UssalKx  1)  <mm  if  mptyil) 
thtn  lru« 
else .... 


Case  analysis  in  theorem  proving  has  been  emphasized  by  Bledsoe  and 
Tyson  [1977].  Other  program-synthesis  systems  that  form  conditional 
expressions  by  case  analysis  have  been  implemented  by  LucKham  and 
Buchanan  [1974]  arnf  Warren  [1976]. 


B.  The  Formation  of  Reoursive  Calls 

We  illustrate  the  formation  of  recursive  calls  by  continuing  the  construction  of  the  leisall 
program.  Recall  that  it  remains  to  consider  the  case  in  which  I is  a nonempty  list. 

Cm*  / is  nonempty:  In  this  case  we  fail  to  achieve  Goal  2,  to  prove  that  I is  empty,  and 
therefore  we  look  for  some  alternate  means  for  approaching  Goal  i,  computo  x < 

Another  rule  that  applies  to  Coal  I is  the  all  decomposition  rule 

P{all(t))  ->  P(fiead{l))  and  P(aIlUallU))  if  / is  a nonempty  list . 

This  rule  imposes  the  condition 

Goal  3 1 prove  / is  a nonempty  list, 

which  IS  satisfied  immediately  because  we  have  assumed  in  our  case  analysis  that  / is  nonempty. 
The  rule,  therefore,  transforms  Coal  I into 

Goal  4i  compute  x < htad{l)  and  x < aU{taiHl)). 

To  compute  the  truth  value  of  x < fitad{l)  is  simple,  because  x and  / are  inputs,  and  h*ad  is 
a primitive  construct.  It  remains,  therefore,  to  achieve 

Goal  6i  compute  x < alt(tai(U))  . 

Note  that  this  subgoal  it  an  instance  of  our  original  Goal  I,  to  compute  x < (UKO,  with  inputs  x 
and  / replaced  by  x and  taiHO.  This  is  an  opportunity  for  applying  the  r*cursion~/ormatlon 
rvdt. 
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In  general,  suppose  we  are  to  develop  a program  whose  specifications  are 
of  form 

/(x)  <-•  compute  F(x) 
where  Q(x) , 

in  which  Q(x)  is  a condition  but  F(x)  may  be  any  expression  in  the 
specification  language.  Assun>e  we  encounter  a subgoal 

compute  PU) 

that  is  an  instance  of  the  output  specification  compute  P(x).  Then  we  can 
attempt  to  achieve  this  subgoal  by  forming  a recursive  caliyfr),  because  the 
program  /(x)  is  intended  to  compute  P(x)  for  any  x that  satisfies  Q(x).  To 
ensure  that  the  introduction  of  this  recursive  call  is  legitimate,  we  must  ' 
verify  two  conditions: 

• The  inpul  condition,  Q^t),  which  establishes  that  the  argument  t of  the 
recursive  call  f{t)  satisfies  the  required  input  condition  of  the  desired  ‘ 
program;  otherwise,  the  program  / is  not  guaranteed  to  yield  the  expected 
output. 

• A termination  condition,  which  ensures  that  the  recursive  call  cannot 
cause  an  infinite  computation.  A recursive  call  can  fail  to  terminate  if  its 
execution  leads  to  another  recursive  call,  which  leads  to  another,  and  so  on 
indefinitely. 

The  termination  condition  is  expressed  in  terms  of  the  "well-founded 
set"  concept,  which  will  be  explained  in  a later  section  devoted  exclusively 
to  termination.  In  the  meantime,  we  will  appeal  to  intuitive  arguments  to 
establish  termination. 

NcKe  that  to  ensure  that  the  recursive  csU/^t)  be  primitive,  we  apply  the 
recursion-formation  rule  only  when  the  argument  t itself  is  primitive. 

Let  us  return  to  our  example.  The  recursion-formation  rule  observes  that  Coal  5,  to 
compute  X < allUailU)),  is  an  instance  of  our  output  specification,  x < allU),  with  inputs  x and  I 
replaced  by  x and  (ail(l>,  therefore  it  proposes  that  we  achieve  this  goal  with  a recursive  call 
UsscUfix  tailU)).  For  this  purpose,  the  rule  imposes  two  conditions,  the  input  condition 

Goal  6 1 prove  lai/(0  is  a list. 


and  the  termination  condition 
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Qoal  7 1 prove  ttssallix  tailU))  terminates. 

The  input  condition  that  lail(l)  is  a list  can  be  proved  directly  by  invoking  a transformation 
tai/U)  IS  a list  ->  true  if  / is  a list , 


a basic  rule  describing  list  structures.  To  achieve  the  termination  condition  is  also 
straightforward,  because  the  argument  tail(l)  of  the  recursive  call  is  a proper  sublist  of  the 
input  /;  therefore  only  a finite  number  of  recursive  calls  can  occur  before  the  second  argument 
IS  reduced  to  the  empty  list.  Consequently,  we  are  permitted  to  introduce  a recursive  call 
lessallix  lailU))  at  this  point.  This  satisfies  Coal  5;  Goal  4 is  then  satisfied  by  the  program 
segment  x < htadd)  and  lessall{x  tail{l)).  This  segment  is  composed  entirely  of  primitive 
constructs  of  our  target  language. 


We  have  succeeded  in  finding  primitive  program  segments  that  solve  our  problem  in  both 
cases,  whether  / is  empty  or  not.  Therefore  the  conditional-formation  rule  combines  the  two 
program  segments  into  a conditional  expression.  The  final  program  is 


lessalUx  /)  <-•  if  emptj{l) 
then  true 

else  X < headd)  and  lessalKx  talld))  ■ 

The  above  technique  causes  the  formation  of  a recursive  program.  If  we  are  working  in  a 
target  language  that  does  not  admit  recursion,  it  is  necessary  to  transform  the  program  further, 
to  replace  the  recursion  by  another  repetitive  construct.  In  many  cases,  a recursive  program  can 
be  transformed  into  an  iterative  program  of  comparable  complexity.  In  the  worst  case,  we  can 
always  replace  a recursive  procedure  with  an  iterative  equivalent  by  the  explicit  introduction  of 
a stack. 


The  above  recursion-formation  rule  is  the  same  as  the  'folding*  rule  of  the 
Burstall  and  Darlington  [1977]  system  for  the  transformation  of  recursive 
programs.  Their  system  does  not  check  the  input  and  termination  conditions. 


C.  Termination 

In  the  preceding  example  we  relied  on  intuitive  argumenu  to  establish  the  termination  of 
the  program  we  constructed.  In  fact,  for  that  example,  the  termination  argument  was  quite 
straightforward.  In  this  section,  we  will  consider  a general  mechanism  for  proving  the 
termination  of  a recursive  program  at  the  same  time  as  it  is  being  constructed.  We  will 
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illustrate  this  mechanism  with  an  example  for  which  the  termination  proof  is  somewhat  more 
subtle. 


The  program  we  construct  is  intended  to  compute  the  greatest  common  divisor,  gcd{x  y),  of 
two  nonnegative  integers  x and  y.  The  specifications,  as  indicated  In  Section  lA,  are  expressed 
as 


gcd(x  y)  <»  compute  max{z  ; z|x  and  z|^) 

where  x and  y are  nonnegative  integers  and 
X K 0 or  j K 0 . 

Recall  that  the  input  condition  x « 0 or  ^ « 0 is  imposed  because  the  gcd  is  not  defined  when 
both  its  arguments  are  zero. 

The  output  specification  is  expressed  in  terms  of  the  set  constructor  {u  : P(u)}.  which  Is  not 
primitive  We  therefore  attempt  to  transform  it  into  an  equivalent  primitive  description. 

We  assume  that  the  following  rules  about  the  integers  are  Included  among  the 
transformations  of  our  system: 

u|t>  » triu  if  V • 0 

(every  integer  divides  0) , 

ujv  and  u|iv  •>  u\o  and  u|u/-v 

(the  common  divisors  of  v and  to  are  the  same  as  those  of  v and  w-v),  and 
maxju  : u|v}  •>  v if  tt  is  a positive  integer 
(every  positive  integer  is  its  own  greatest  divisor). 

As  usual,  our  first  goal  is  derived  directly  from  the  output  specification; 

Goal  1 : computo  max{z  : z|x  and  z|y} . 

There  are  at  least  two  rules  that  match  the  subexpression  z|x  and  z|y,  they  are  the  logical 
rule 

P and  Q ■>  (2  f* 
and  the  nunoerical  rule 

u|v  and  uNv  ->  u|v  and  u|w-v  . 
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Either  rule  will  lead  to  a successful  program;  suppose  we  attempt  the  logical  rule  first.  Then  we 
develop  the  subgoal 

, Goal  2t  computa  max{z  : i\f  and  z|x) . 

s 

Coal  2 is  an  instance  of  Goal  I Itself,  with  x and  y replaced  by  y and  x;  therefore,  the 
recursion-formation  rule  attempts  to  satisfy  Coal  2 with  a recursive  call  gcd(y  x).  To  ensure 
that  this  step  is  legitimate,  the  rule  imposes  an  input  condition 

Goal  3:  prova  y and  x are  nonnegative  integers  and 
y n 0 or  X e 0 

obtained  by  replacing  x and  y by  y and  x,  respectively,  in  the  input  condition  of  the 
specification  This  condition  is  easily  established,  because  it  is  an  equivalent  form  of  the  given 
input  condition  itself  Furthermore,  the  recursion-formation  rule  imposes  a termination 
condition,  to  ensure  that  the  proposed  recursive  call  terminates  : 

Goal  4i  prove  gcd(y  x)  terminates. 

We  will  begin  by  attempting  to  use  the  same  sort  of  informal  argument  we  employed  in  the 
previous  example  proving  the  termination  of  this  recursive  call.  Later  in  this  example,  we  will 
be  forced  to  introduce  the  more  formal  and  general  apparatus.  To  establish  termination,  it 
suffices  to  achieve 

Goal  6i  prova  y < x , 

because  x and  y are  both  known  to  be  nonnegative  integers  (by  the  input  condition),  and 
because  y is  the  first  argument  of  the  recursive  call. 

If  we  establish  Coal  5,  only  a finite  sequence  of  recursive  calls  can  occur  before  the  first 
argunsent  is  reduced  to  zero.  However,  we  cannot  prove  or  disprove  Coal  5;  x and  y are  both 
input  variables,  and  we  have  no  way  of  knowing  if  one  of  them  is  bigger  than  the  other.  As 
before,  the  conditional-formation  rule  causes  a case  analysis  to  be  introduced. 

Cas*  y < X : Here,  both  the  input  condition  and  the  termination  condition  for  introducing 
the  recursive  call  gcd(y  x)  are  satisfied.  We  have  thus  completed  one  branch  of  the  case 
analysis;  we  have  yet  to  consider  the  alternate  case.  However,  at  this  stage  we  know  that  the 
final  program  will  have  the  form 

fcd(x  y)  <—  i/y  < X 

than  gcd{y  x) 

*ltt .... 
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Case  X i y : Here,  It  is  not  legitimate  to  introduce  the  recursive  call  gcd(y  x)  to  achieve 
Coal  2.  because  the  termination  condition  is  not  satisfied.  Assuming  that  no  other  rules  succeed 
in  reducing  Coal  2 to  a primitive  segment,  we  are  led  to  consider  alternate  means  of  achieving 
the  original  Coal  1 in  this  case. 

Recall  that  among  other  rules  that  applied  to  Coal  I was  the  numerical  rule 
u\v  and  u|tv  ->  u|i;  and  u\w-v  . 

This  rule  causes  the  generation  of  a new  goal 

Goal  0i  compute  max{z  : z|x  and  z()i-x} . 

This  goal  has  the  same  form  as  the  original  Coal  1,  but  with  the  inputs  x and  y replaced  by 
X and  y-x;  the  recursion-formation  rule  suggests  satisfying  Coal  6 with  the  recursive  call 
gcd{x  y-x) . 

To  ensure  that  the  arguments  x and  y-x  are  legitimate,  the  rule  imposes  the  input  condition 

Goal  7:  prove  x and  y-x  are  nonnegative  Integers  and 
X x 0 or  y-x  » 0 ; 

to  guarantee  that  the  proposed  recursive  call  will  terminate,  the  rule  also  imposes  the 

termination  condition 

Goal  8t  prova  gcd{x  y-x)  terminates. 

Let  us  examine  Coal  7 first:  that  x and  y-x  are  nonnegative  integers  follows  from  the 
original  input  specification  and  the  case  assumption  x i y,  the  condition 

X X 0 or  y-x  x 0 

leads  us  to  attempt  to  prove  either 

Goal  0:  prove  x x 0 , 


or 


Goal  lOi  prova  y-x  x 0. 

We  fail  to  prove  or  disprove  Coal  9;  therefore,  the  conditional-formation  rule  Introduces  a 
case  analysis. 
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Case  X ••  0 : Here,  the  input  condition  for  the  proposed  recursive  call  gcdix  y-x)  is 
satisfied;  it  remains  to  show  the  termination  condition  (Goal  8). 

If  this  were  the  only  recursive  call  in  the  entire  program,  its  termination  would  be  easy  to 
establish.  After  all,  we  know  in  this  case  that  x is  a positive  Integer  and  that  y-x  is  a 
nonnegative  integer;  furthermore,  y-x  is  strictly  less  than  the  second  Input  y.  Thus,  each 
execution  of  this  recursive  call  reduces  the  second  argument,  and  only  a finite  number  of 
executions  can  occur  before  the  second  argument  is  reduced  to  zero.  However,  the  program  we 
are  developing  already  contains  another  recursive  call  gcd{y  x);  we  must  consider  the  possibility 
that  an  infinite  computation  involving  both  recursive  calls  might  occur. 

This  IS  a real  possibility,  because  the  recursive  call  gcd{y  x)  actually  increases  the  second 
argument.  We  therefore  must  treat  both  recursive  calls  at  once,  and  this  requires  a more 
sophisticated  mechanism  for  proving  termination  conditions. 


In  general,  to  prove  termination  we  employ  the  concept  of  a well- 
founded  set,  one  whose  elements  are  ordered  in  such  a way  that  no  infinite 
decreasing  sequence  of  elements  can  exist.  For  example,  the  nonnegative 
integers,  under  the  usual  less-than  ordering,  constitute  a well-founded  set, 
whereas  the  entire  set  of  integers  does  not. 

To  prove  the  termination  of  a recursive  program /(x)  with  recursive  calls 
f(t\).  /(f?),  . we  show  that  x,  t^,  tj all  belong  to  some 

well-founded  set  IV,  ordered  by  a relation  <,  and  that 

ri<x,r2^^ ^ ^ ■ 

This  condition  suffices  to  ensure  termination,  because  if  there  were  a 
nonterminating  computation,  it  would  jontain  an  infinite  sequence  of 
recursive  calls,  whose  arguments  would  constitute  an  Infinite  decreasing 
sequence  in  the  well-founded  set.  But  a well-founded  set  contains  no 
infinite  decreasing  sequences. 

By  the  method  we  have  just  deKribed,  to  establish  the  termination  of  a 
program /(x)  with  many  recursive  calls /(r|),  /(fj) we  must  show 

that  each  argument  t^  is  less  than  the  original  input  x under  a single  well- 

founded  ordering  < This  implies  that,  during  the  synthesis  of  the  program, 
whenever  we  introduce  a new  recursive  call  f{t^)  we  must  show  that  r^  < x 

under  the  same  ordering  < which  we  have  used  to  establish  the  termination 
of  the  recursive  calls /(f|),  /(t*) AU-0>  introduced  previously.  If  we 
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cannot,  we  must  modify  the  well-founded  set  W and  the  ordering  < so  that 

fj  < X.  while  ensuring  that  the  relations  I,  < x,  < x < x are 

still  satisfied. 

If  the  program  has  more  than  one  argument,  the  ordering  < of  the  well- 
founded  set  may  need  to  compare  pairs  or  tuples  of  arguments.  For  this 
purpose  it  is  convenient  to  use  the  lexicographic  ordering  between  tuples. 
For  paifs  of  nonnegative  integers,  for  example,  this  ordering  is  defined  as 
follows; 


(x,  xj)  < (y,  yg)  if  X|  < yi  . or  if  x,  - y,  and  Xg  < yj  . 

Thus,  the  second  components  are  ignored  unless  the  first  components  are 
equal  This  lexicographic  ordering  can  be  shown  to  be  well-founded;  there 
exist  no  infinite  sequences  of  pairs  of  nonnegative  integers  that  decrease 
under  this  ordering.  A general  notion  of  lexicographic  ordering  on 
arbitrary  tuples  of  elements  can  be  defined  in  a similar  way. 

In  the  gcd  example,  we  have  already  proved  the  termination  condition  of  the  recursive  call 
gc(i(y  x)  by  showing  that  the  first  argument  y of  the  recursive  call  is  less  than  the  first  input  x; 
in  other  words,  we  have  used  the  ordering  < defined  by 

(U|  Ug)  < (v,  Vg)  if  u,  < V,  . 

This  IS  a well-founded  ordering  between  pairs  of  nonnegative  integers.  Thus,  in  proving  the 
termination  condition  for  the  proposed  new  recursive  call  gcd(x  y-x),  we  attempt  to  show  that 

(x  y-x)  < (x  y) 

under  this  ordering,  i e..  that  x < x.  This  attempt  fails;  the  first  argument  is  not  reduced  by  the 
proposed  recursive  call.  We  therefore  try  to  modify  the  ordering  < to  establish  the  termination 
condition  for  the  second  recursive  call  as  well. 

The  first  argument  x of  the  proposed  recursive  call  gcd(x  y-x)  is  nonnegative  and  is 
identical  to  the  first  input  x;  we  have  also  seen  that  the  second  argument  y-x  is  a nonnegative 
integer  (since  we  have  assumed  that  x s y)  and  is  less  than  the  second  input  y (since  x is 
positive  in  this  case). 

This  suggests  that  we  modify  the  ordering  < to  be  the  lexicographic  ordering.  This  ordering 
will  allow  us  to  prove  the  termination  conditions  for  both  recursive  calls. 

The  use  of  the  recursive  call  gcd(x  y-x)  has  been  justified  in  this  case,  because  Its  input 
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condition  (Coal  7)  and  its  termination  condition  (Coal  8)  have  been  established.  The  partial 
program  we  have  constructed  so  far  is 

gcd{x  y)  <--  if  y < X 

(fun  gcd(  y x) 
tin  t/  X •»  0 

then  gcdix  y-x) 
tlit  .... 

We  have  yet  to  consider  the  case  in  which  x - 0 . 

Case  X • 0 : In  this  case,  the  recursion-formation  rule  fails  to  introduce  the  recursive  call 
gcrf(x  y-x)  because  we  cannot  establish  its  termination  condition;  indeed,  if  we  did  introduce 
this  recursive  call,  the  program  would  certainly  not  terminate.  Instead,  we  look  for  some 
alternate  means  of  satisfying  Coal  6, 

computa  m(jx{z  ; z|x  and  z|;y-x} , 

which,  since  x - 0,  is  reduced  to 

Goal  1 1 : compute  max{z  : z|0  and  z(y} . 

By  application  of  the  three  rules 

u\v  •>  true  if  V • 0, 

true  and  P P , and 

max{u  ; ulv)  ->  v if  i>  is  a positive  integer 

in  succession,  we  obtain 

Goal  12;  compute  y . 

The  last  rule  could  be  applied  because  in  this  case  x - 0,  and  thus  y e 0 (since  x k 0 or  y k 0), 
and  y > 0 (since  y is  nonnegative). 

Now  y IS  a primitive  program  segment  that  solves  our  problem  in  this  final  case.  The 
complete  gcd  program  is 

gcdix  y)  <--  if  y <x 

then  gcdiy  x) 
else  if  X » 0 

then  gcdix  y-x) 
else  y . 
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This  is  a version  of  the  "subtractive"  gcd  algorithm. 


Well-founded  orderings  were  first  invoked  to  prove  properties  of 
recursive  programs  by  Burstall  [1969],  The  theorem-proving  system  of 
Boyer  and  Moore  [1977]  also  constructs  lexicographic  orderings. 

The  particular  program  we  obtain  depends  on  the  transformation  rules  we  have  at  our 
disposal  and  the  choices  we  make  during  the  derivation  process.  For  example,  if  we  had  the 
additional  rules 

gcd(,u  v)  ->  2-gcd{ul2  vl2)  if  u and  v are  even, 
gcd{u  v)  ->  gcd(ul2  v)  if  u is  even  and  v is  odd,  and 

gcd{u  v)  ->  gcd(u  vl2)  if  u is  odd  and  v is  even, 

we  could  have  obtained  the  "binary"  gcd  program 

gcd(x  y)  <•’•  if  evtn{x) 

then  if  even{y) 

then  2- gcd(xl2  yl2) 
else  gcd{xl2  y) 
else  if  even(y) 

then  gcd(x  y/2) 
else  if  y < X 

then  gcdiy  x) 
else  if  X K 0 

then  gcd{x  y-x) 
else  y . 

This  program  turns  out  to  be  quite  efficient  for  implementation  on  a binary  machine,  in  which 
division  and  multiplication  by  two  can  be  represented  as  right  and  left  shifts,  respectively  (or 
vice  versa,  depending  on  which  side  of  the  machine  we  are  standing  on).  Of  course,  nothing  in 
the  technique  guarantees  that  an  efficient  program  will  be  derived. 


D.  Strategic  Controls 

Up  to  now  we  have  developed  programs  by  applying  transformation  rules  to  goals  without 
considering  how  to  select  the  rule  to  be  applied;  the  proper  rule  seemed  to  appear  by  magic 
when  It  was  relevant.  If  we  have  hundreds  of  rules  at  our  disposal,  how  do  we  retrieve  the 
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applicable  ones?  Of  the  many  rules  that  can  be  applied  in  a given  situation,  not  all  will  lead  to 
a primitive  program.  If  more  than  one  rule  applies  to  a goal,  how  do  we  decide  which  to 
attempt? 

If  the  program  is  being  developed  by  hand,  we  can  rely  on  the  programmer's  knowledge  and 
intuition.  However,  if  we  expect  this  process  to  be  performed  by  an  automatic  synthesis  system, 
the  basis  for  our  strategic  decisions  must  be  made  explicit.  In  this  section,  we  will  discuss  some 
strategic  methods  for  directing  the  transformation  rules. 

The  strategic  controls  that  we  have  incorporated  into  our  own  program-synthesis  system  may 
be  outlined  as  follows  When  a goal  is  proposed,  the  rules  that  seem  applicable  are  selected  by 
pattern-directed  invocation.  Of  all  the  selected  rules,  one  is  chosen  according  to  a given  ru/e 
ordering,  this  rule  is  attempted  first.  Each  rule  may  be  provided  with  a number  of  strategic 
conditions,  which  prevent  it  from  being  applied  foolishly.  If  the  strategic  conditions  are  not 
satisfied,  or  if  the  rule  does  apply  but  does  not  lead  to  a primitive  program,  we  backtrack  and 
consider  the  next  applicable  rule  chosen  by  the  rule  ordering.  Let  us  discuss  each  of  these 
methods  in  more  detail. 

• Pattern-directed  invocation.  The  rules  are  indexed  by  the  patterns  to  which  they  can  be 
applied  For  example,  the  all  decomposition  rule 

P(aUU))  ->  P(fiead{l))  and  P{aiHtail{l)))  if  / is  a nonempty  list 

IS  classified  according  to  its  left-hand  side,  P{all(l)).  When  a new  goal  is  proposed,  all  those 
rules  whose  patterns  match  the  goal  are  retrieved.  Thus,  the  above  rule  and  the  vacuous  rule 

P(all(l))  •>  true  if  / is  the  empty  list, 

would  both  be  invoked  when  the  goal  compute  x < all(l)  ts  proposed  This  method  of 
retrieving  a rule  when  it  seems  applicable  iS  termed  pattern-directed  invocation. 

• Ru/e  ordering  It  often  happens  that  more  than  one  transformation  rule  will  match  the  same 
goat.  However,  sometimes  we  can  decide  a priori  that  one  rule  should  be  attempted  before 
another  For  example,  if  the  vacuous  rule 

PialKD)  ->  t’’ue  if  I is  the  empty  list 

and  the  recursion-formation  rule  both  match  the  same  goal,  the  vacuous  rule  should  always  be 
attempted  first,  the  recursion-formation  rule  imposes  the  input  and  termination  conditions, 
which  may  be  time-consuming  to  verify.  Furthermore,  if  both  rules  do  apply,  the  program 
segment  true  is  preferable  to  a recursive  call. 

On  the  other  hand.  If  the  decomposition  rule 
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P(atl{l))  ->  P(htad(l))  and  P(all(taU(l))  if  / is  a nonempty  list 

and  the  recursion-formation  rule  both  match  the  same  goal,  we  prefer  to  attempt  the  recursion- 
formation  rule  first;  the  decomposition  rule  produces  a nonprimitive  subgoal  more  complex 
than  the  original  goal,  while  the  recursion-formation  rule  Is  guaranteed  to  produce  a primitive 
recursive  call. 

• Strategic  conditions:  We  have  seen  that  a transformation  rule  may  impose  logical  conditions, 
which  must  be  satisfied  to  ensure  a valid  application  of  the  rule.  By  the  same  token,  a rule 
may  have  strategic  conditions,  which  prevents  it  from  being  applied  foolishly.  For  example,  in 
introducing  a conditional  expression  if  P then  j,  else  S2  or  the  recursive  call  f{t)  we  imposed 
the  strategic  condition  that  the  condition  P or  the  argument  t be  primitive;  this  was  to  ensure 
that  the  resulting  expression  would  itself  be  primitive. 

Two  more  examples:  if  we  introduce  the  logical  rule 

P and  Q ->  Q and  P , 

or  the  integer  rule 

u|i;  and  u|tv  •>  u|v  and  u\w-v  , 

we  must  give  them  each  strategic  conditions  to  ensure  that  they  are  not  applied  repeatedly  to 
the  subexpressions  that  they  themselves  produce;  otherwise,  we  may  obtain  an  endless  sequence. 


P and  Q , Q and  P , P and  Q , ...  . 

Good  strategic  conditions  improve  the  general  performance  of  a system,  but  they  may 
prevent  it  from  finding  some  trickier,  less  intuitive  solutions. 

• Backtracking:  If  applying  one  rule  to  a goal  fails  to  lead  to  a primitive  program  segment, 
the  system  will  backtrack,  and  attempt  to  apply  other  applicable  rules  to  the  same  goal. 

For  instance,  in  constructing  the  gcd  program,  we  applied  the  rule 

P and  Q •>  Q and  P 


to  Coal  I, 


compute  max\t : z\x  and  2|y} , 


to  form  Coal  2, 
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compute  maxjz  : z|^  and  ztx) 

In  the  ease  in  which  x i y,  we  failed  to  derive  a primitive  program  segment  from  Goal  2; 
therefore,  we  backtracked  and  considered  other  rules  that  matched  Coal  I.  As  it  turned  out, 
the  rule 


u|i;  and  ultv  ->  uiv  and  \i\iu-v 
applied  to  Coal  I to  yield  Coal  6, 

compute  maxjz  : z|x  and  i|y-x} . 

In  addition  to  these  general  strategic  methods  for  controlling  transformation  rules,  there  are 
special  strategic  techniques  associated  with  particular  rules.  One  of  these  techniques  is  the 
subject  of  the  next  subsection 


Pattern-direcled  invocation  was  introduced  as  a feature  of  tha  PLANNER 
programming  language  for  artificial -intalligarKa  research  (Hewitt  [1971]). 


Tho  Rodundant-Taat  Strategy 

The  conditional-formation  rule  will  introduce  a case  analysis  when  we  fall  to  prove  or 
disprove  a condition  P We  consider  separately  the  case  in  which  P is  true  and  the  case  in 
which  P IS  false,  construct  program  segments  i|  and  i;  to  handle  each  case,  and  combine  these 
segments  into  the  conditional  expreuion 

if  P Ifitn  S|  tlse  Sj  . 

However,  it  is  possible  that  one  of  these  segments,  uy  ij.  does  not  depend  on  the  corresponding 
case  assumption,  that  P is  false.  In  this  situation,  the  segment  S]  Itself  will  solve  our  problem 
regardless  of  whether  P is  true  or  false,  constructing  the  other  segment  j|  would  be  a waste  of 
effort 

The  rtdundanl-tttl  slrattgy  prevents  such  irrelevant  conditional  expressions  from  being 
formed  According  to  this  strategy,  in  introducing  a case  analysis  we  always  consider  first  the 
negative  case.  In  which  P is  false  If  we  then  succeed  in  constructing  a program  segment  S}  that 
solves  our  problem  without  ever  using  the  case  assumption  that  P Is  false,  then  this  segment 
solves  the  entire  problem  We  do  not  consider  the  positive  case.  In  which  P Is  true,  and  we  do 
not  generate  a conditional  expression 
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We  always  consider  the  negative  case  first  because  In  the  positive  case,  the  assumption  that 
P IS  true  will  always  be  used  by  the  rule  that  imposed  the  condition;  therefore,  we  can  never 
escape  considering  the  negative  case. 

For  example,  suppose.  In  constructing  the  ged  program,  we  are  given  the  rtm  rule 
u|v  and  u|n>  ->  uju  and  u\rem{w  v)  if  v m 0 
instead  of  the  minus  rule 

u|v  and  u|w  •>  u|t;  and  u|w-v  , 

where  u,  v,  and  w are  nonnegative  integers.  (The  rem  rule  states  that  the  common  divisors  of 
V and  w are  the  same  as  the  common  divisors  of  v and  rem{w  v).)  Recall  that  in  developing  our 
previous  ged  program,  we  introduced  a case  analysis  on  the  condition  31  < x in  an  attempt  to 
introduce  a recursive  call  gcd(y  x).  Now,  according  to  the  redundant-test  strategy,  we  will  first 
consider  the  negative  case,  in  which  x i y.  In  this  case  we  will  apply  the  rem  rule  and 
eventually  develop  the  program  segment 

i/x  - 0 

l/ien  gcd(rtm(y  x)  x) 
else  y 

without  ever  using  the  case  assumption  that  x i y.  Consequently,  we  need  never  consider  the 
positive  case,  in  which  y < x The  above  segment  solves  the  entire  problem,  so  our  final 
program  is  simply 

gcd{x  y)  <--  if  X 0 0 

then  gedfremiy  x)  x) 
else  y 

This  IS  a version  of  the  Euclidean  ged  algorithm. 

In  describing  a program  derivation  in  which  a case  analysis  is  introduced  and  later 
eliminated  by  the  red  undent -test  strategy,  we  will  often  omit  mentioning  the  case  analysis 
altogether  For  example,  in  developing  either  of  the  above  ged  programs,  we  introduce  a case 
analysis  on  the  caidiuon  y • 0 as  well  u on  the  condition  x - 0,  this  case  analysis  on  y > 0 is 
eliminated  by  the  redundant  test  strategy,  and  never  appears  in  our  discussion. 
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3.  EXTENSIONS  OF  RECURSION  FORMATION 
A.  Oeneralization 

Recursive  calis  have  been  introduced  when  a new  subgoal  is  discovered  to  be  a precise 
instance  of  the  top-level  goal.  But  what  if  the  subgoal  is  an  instance  not  of  the  top-level  goal 
but  of  a somewhat  more  general  expression?  In  such  cases,  it  may  be  advisable  to  construct  a 
new  procedure  (or  subroutine)  to  compute  the  more  general  expression,  and  to  achieve  our 
original  goal  by  a call  to  the  new  procedure.  Although  the  new  procedure  attempts  to  solve  a 
more  general  problem,  that  problem  may  nevertheless  be  easier  to  solve. 

Ceneraliration  is  already  commonplace  in  the  theorem-proving  context:  paradoxically,  It  is 
often  necessary,  in  proving  a theorem  by  mathematical  Induction,  to  prove  a more  general 
theorem,  so  that  the  induction  hypothesis  will  be  strong  enough  to  prove  the  inductive  step.  In 
program  synthesis,  induction  is  analogous  to  recursion:  we  attempt  to  construct  a program  to 
compute  a more  general  goal  so  that  the  recursive  call  will  be  strong  enough  to  achieve  the 
desired  subgoal. 

As  before,  we  will  explain  the  method  In  the  context  of  an  example.  We  will  not  follow  the 
precise  order  dictated  by  the  strategic  controls  in  constructing  the  program.  Because  we  have 
considered  a similar  program,  lessall(x  1),  previously,  we  will  be  a bit  more  brief  in  our 
exposition. 

Suppose  we  want  to  construct  a program  headtail(l)  to  test  whether  the  head  of  a nonempty 
list  t IS  less  than  every  element  of  its  tail.  The  specifications  for  this  program  may  be  expressed 
as 

headtail(l)  <—  compute  headU)  < ali(laiHl)) 

where  / is  a nonempty  list  of  numbers. 

Our  top-level  goal  is  then 

Goal  1 1 compute  htad{l)  < all{tallU)) . 

Recall  that  we  have  Introduced  two  rules  that  explicate  the  all  construct:  the  vacuous  rule 
P(all(l))  ->  trut  If  I it  the  empty  list, 
and  the  decomposition  rule 

Piaim))  »>  P(htad(l))  and  P{all(tail{l))  if  / is  a nonempty  list. 


These  rules,  together  with  the  conditional-formation  rule,  account  for  the  Introduction  of  a case 
analysis  into  our  derivation,  and  the  subsequent  formation  of  a conditional  expression  in  our 
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final  program.  In  the  case  that  t<Ul{l)  is  empty,  the  vacuous  rule  reduces  the  goal  to  the 
primitive  segment  true;  in  the  other  case,  in  which  tai/(0  is  not  empty,  the  decomposition  rule 
reduces  the  goal  to  computing  the  conjunction  of  two  expressions: 

Goal  2;  compute  htadU)  < htad(fail{l)) 

and 


Goal  3:  compute  htad(l)  < all{tail{t<UHl))) . 

Coal  2 is  already  a primitive  expression.  We  hive  yet  to  consider  Goal  3;  however,  the 
program  constructed  so  far  is 

fieadtailU)  <—if  tmpty(tailU)) 
then  true 

else  headU)  < head{tail(l))  and 


An  atten.pt  to  satisfy  Coal  3 by  the  recursion-formation  rule  fails,  because  Goal  3 is  not  a 
precise  instance  of  Coal  1, 

compute  headU)  < all{tail{l)) ; 

the  / on  the  left-hand  side  of  Goal  I corresponds  to  / in  the  subgoal,  but  the  I on  the  right- 
hand  side  corresponds  to  tailfl).  However,  Coal  3 is  an  instance  of  a more  general  goal. 

Goal  1 (generalized)]  compute  head{lx)  < aU{taU{l^)  , 

obtained  from  Coal  I by  introducing  new  variables  /|  and  li  in  place  of  the  left-  and  right- 
hand  occurrences  of  /,  respectively.  This  suggesO  that  we  attempt  to  construct  a procedure 
headtallgenUx  Ij)  to  achieve  the  generalized  Coal  I inuead  of  the  original  version.  Thus,  the 
output  specification  for  the  new  procedure  will  be 

headtail genii t I2)  <--  compute  A<ad(/|)  < allitttil{l2))  . 

This  procedure  will  test  whether  the  head  of  /|  is  less  than  every  element  of  the  tail  of  /j,  where 
/i  and  1 2 may  be  distinct  lists. 

We  can  now  set  aside  our  original  derivation,  and  satisfy  the  original  Goal  I by  a call  to  the 
more  general  procedure  instead;  the  resulting  headtail  program  will  be  simply 


headtaUil)  <•■  headtailgenil  1)  . 
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It  remains  to  construct  the  more  general  procedure  htadtallgtn,  l.e.  to  achieve  the 
generalized  Coal  I.  The  derivation  of  the  generalized  goal  will  attempt  to  mirror  the  original 
derivation;  our  hope  is  that  this  time  the  top-level  goal  Is  general  enough  so  that  the  previous 
obstacle  encountered  in  introducing  the  recursive  call  will  be  overcome. 

In  general,  suppose  we  are  developing  a program  whose  specifications 
are  of  form 

f(x)  <—  compute  P(a(x)) 
where  Q^x) . 

Then  our  top-level  goal  is  of  form 

Goal  A:  compute  P{a(x)) . 

Suppose  that  in  developing  the  program  we  encounter  a subgoal 
Goal  B:  compute  P(b(x)) 

that  is  not  an  instance  of  Goal  A,  but  that  is  an  instance  of  the  more 
general  expression 

compute  P(y). 

Then  the  gtntTotization  rule  proposes  that  we  attempt  to  construct  a new 
procedure  whose  output  specification  is 

g(j)  <mm  compute  P(y)  . 

We  can  thus  satisfy  the  original  Goal  A by  a call  to  the  new  procedure;  the 
resulting  program  / will  be 

/[*)  <—  g{a(x))  . 

To  ensure  that  the  calls  to  the  new  procedure  g will  be  primitive,  we  do 
not  apply  the  generalization  rule  unless  a(x)  and  Hx)  are  primitive. 

The  top-level  goal  of  the  new  derivation  will  be  the  generalized  Goal  A, 
compute  P{y).  We  will  attempt  to  mirror  the  steps  of  the  original 
derivation;  that  is,  we  Cry  to  apply  to  Che  new  goal  the  same  rules  that  we 
applied  earlier  to  the  original  Goal  A in  deriving  the  original  Coal  B.  Our 
hope  is  that  the  goal  in  the  new  derivation  corresponding  to  the  original 
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Coal  B will  turn  out  to  be  an  instance  of  the  generalized  Goal  A,  and  that 
It  will  be  achieved  by  a recursive  call  to  g.  However,  there  Is  no  guarantee 
that  the  same  sequence  of  rules  will  be  applicable  to  the  generalized  Coal  A, 
or  that  if  we  succeed  in  deriving  a generalized  Coal  B,  It  will  turn  out  to  be 
an  instance  of  the  generalized  Goal  A If  the  derivation  fails  for  either 
reason,  we  abandon  the  generalization  and  look  for  other  ways  to  achieve 
the  original  Goal  B (This  is  a very  conservative  strategy;  a more 
adventurous  approach  would  be  to  try  to  use  as  much  as  possible  of  the 
original  derivation,  but  to  seek  other  ways  of  progressing  when  the  original 
derivation  fails.) 

We  have  postponed  describing  the  input  specification  for  the  new 
procedure  g.  It  is  to  our  advantage  to  have  as  few  conditions  in  this 
specification  as  possible,  because  we  must  check  each  of  these  conditions 
every  time  a procedure  call  to  g is  introduced.  For  this  reason,  rather  than 
attempting  to  formulate  the  new  input  specification  in  advance,  we  prefer  to 
prixeed  with  the  derivation  of  g and  add  to  the  input  specification  only 
those  conditions  that  are  needed  to  complete  the  derivation.  In  other  words, 
we  form  the  input  specification  for  g incrementally. 

Thus,  if  in  the  course  of  the  derivation  we  fail  to  prove  a desired 
condition  5(y),  we  consider  adding  this  condition  to  the  input  specification 
of  g However,  every  time  a call  g(u)  to  the  procedure  g has  been 
introduced  previously  in  the  synthesis,  we  must  go  back  and  check  that  the 
additional  input  condition  S(u)  is  satisfied.  In  particular,  because  the  main 
program 


fix)  <—  g(a(x)) 

contains  a procedure  call  g(a(x)),  we  must  check  that  condition  5(a(x))  is 
satisfied. 

Often,  conditions  are  added  to  the  input  specification  simply  to  ensure 
that  the  output  specification  is  meaningful. 

Returning  to  our  example,  we  attempt  to  construct  the  more  general  procedure 
headlallgend I fj)  achieves  the  generalized  Goal  I, 

comput*  headU\)  < a/fftof/f/;))  ■ 

However,  this  goal  is  not  meaningful  unless 

/|  and  1 2 are  nonempty  lists. 
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We  cannot  prove  this  condition  about  our  arbitrary  inputs  l\  and  1^,  therefore,  we  must  add  It 
to  the  input  specification  for  the  new  procedure.  Because  the  main  program  htadtallU)  contains 
the  call  headiailgen(l  /),  we  first  check  that  the  arguments  I and  I for  the  call  satisfy  the 
proposed  condition.  Thus,  we  have  to  show  that 

I and  / are  nonempty  lists. 


i.e.. 


/ is  a nonempty  list. 

But  this  is  exactly  the  input  specification  for  the  main  program. 

We  attempt  to  apply  to  the  generalized  Coal  I the  same  sequence  of  rules  that  we  applied  to 
the  original  Goal  I earlier.  Applying  the  vacuous  rule  in  the  case  where  tall(l2)  is  empty,  we 
derive  the  primitive  program  segment  trur,  applying  the  decomposition  rule  in  the  case  where 
tailUj)  IS  not  empty,  we  decompose  the  generalized  Goal  I into  computing  the  conjunction  of 
two  expressions: 

Goal  2 (ganeralizad):  compute  head{l^)  < 


and 


Goal  3 (genarallzed)i  compute  head{lf)  < all(tail{tall{l2)))  . 

The  new  Coal  2 is  a primitive  expression  as  before;  however,  this  time  the  new  Coal  3 is  a 
precise  instance  of  the  generalized  Coal  I 

compute  Aead(/|)  < all(tail(t2)) ; 

therefore,  the  recursion-formation  rule  proposes  that  we  achieve  the  generalized  Goal  3 by  a 
recursive  call  htadtaitginU\  t(UlU2))  to  the  new  procedure.  The  arguments  /|  and  taU{l2)  can  be 
shown  in  this  case  to  satisfy  the  input  condition  that 

/|  and  taU{l2)  are  nonempty  lists, 

because  and  >re  nonempty  lists  (the  new  input  condition)  and  taii{t2)  is  not  empty  (the  case 
assumption).  T he  termination  condition  is  established  because  the  second  arguntent  ZofA/z)  of 
the  recursive  call  is  a sublist  of  the  second  input  /z- 

The  complete  final  program  is  then 

htadtaiKD  fitadtailgtnU  1) 
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where 

/leadtailgenUt  I2)  <--  if 

thtn  true 

elsthtadU\)  < htad(taU(l^)  and 
headlail genii  ^ taUil2))  ■ 

When  It  IS  successful,  the  generalization  principle  results  in  the  construction  of  a stronger 
program  than  originally  required.  If  the  new  specifications  are  too  general,  however,  the 
corresponding  program  can  actually  be  more  difficult  to  construct  than  the  original.  For  this 
reason,  we  must  impose  conservative  strategic  controls  on  the  application  of  the  generalization 
principle  For  all  the  examples  in  this  paper,  the  only  generalizations  required  involve 
replacing  a constant  by  a variable,  or  one  occurrence  of  a variable  by  a new  variable;  in 
general,  it  is  necessary  to  replace  more  complex  terms  by  variables. 


For  examples  of  theorem-proving  systems  that  generalize  the  theorems 
they  are  about  to  prove  by  induction,  see  Boyer  and  Moore  [1975],  Brotz 
[1973],  and  Aubin  [1975] . SiKlossy  [1974]  proposed  applying  this  technique 
to  program  synthesis. 


B.  The  Formation  of  Subsidiary  Procedures 

We  form  a recursive  call  when  a subgoal  is  discovered  to  be  an  instance  of  the  top-level 
goal.  But  what  if  the  subgoal  Is  an  instance,  not  of  the  top-level  goal,  but  of  some  other 
subgoal?  In  this  section,  we  show  how  such  a situation  can  lead  to  the  formation  of  subsidiary 
procedures  (or  subroutines) . 

As  before,  we  will  consider  the  general  case  in  the  context  of  a specific  example.  The 
program  to  be  constructed,  allallU  m),  is  intended  to  test  whether  every  member  of  a given  list  I 
of  numbers  is  less  than  every  member  of  another  such  list  m.  The  specifications  can  be 
expressed  as 

ailallU  m)  <••  compute  alUl)  < altim) , 

where  I and  m are  lists  of  numbers. 

The  top-level  goal  is  thus 

Goel  1 1 compute  ailU)  < ailim) . 

As  before,  we  will  employ  the  vacuous  rule 
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P(aU{l))  •>  true  if  / is  the  empty  list 
and  the  decomposition  rule 

P(aU{l))  ->  P{headU))  and  P(all(tail(l)))  if  / is  a nonempty  list. 

In  the  case  in  which  I is  empty,  the  vacuous  rule  reduces  Goal  1 to  the  primitive  program 
segment  true,  in  the  other  case,  the  decomposition  rule  reduces  the  goal  to  computing  the 
conjunction  of  two  expressions: 

Goal  2:  computa  head{l)  < <Ul{m) 


and 


Goal  3:  computa  cUHtailQ))  < . 

Coal  3 IS  discovered  to  be  an  instance  of  the  top-level  goal,  with  the  inpuU  I and  m replaced 
by  tailU)  and  m.  Therefore,  the  recursion-formation  rule  replaces  this  goal  by  a recursive  call 
lessall(taiHl)  m);  the  input  condition  is  easily  checked,  and  the  termination  condition  is  proved 
because  tailU)  is  a proper  sublist  of  t. 

We  have  yet  to  consider  Coal  2;  the  program  constructed  so  far  has  the  form 

allot l{l  m)  <mm  if  emptyil) 
then  true 
else  . . . and 

allallUailU)  m) . 

Coal  2,  compute  head(l)  < all(rn),  is  decomposed  in  a manner  similar  to  Goal  1.  In  the  case 
where  m is  empty,  the  vacuous  rule  transforms  this  expression  to  the  primitive  program 
segment  true  In  the  other  case,  the  decomposition  rule  reduces  this  goal  to  computing  the 
conjunction  of  two  expressions. 

Goal  4;  compute  head{l)  < head{m) 


and 


Goal  S:  computa  head{l)  < all{tall{rn)) . 

Coal  4 is  a primitive  expression  that  can  be  computed  directly.  Coal  5 is  an  instance  not  of 
the  top-level  goal  but  of  the  intermediate  Goal  2,  computa  head(l)  < all(rn),  with  the  inputs  I 
and  m replaced  by  I and  fal/(m).  This  suggests  that  we  might  achieve  Goal  5 by  a recursive  call 
not  to  the  entire  program  eUlall  but  to  the  segment  of  allall  that  achieves  Coal  2.  For  this 
purpose,  we  must  introduce  a subsidiary  procedure  headallU  m)  corresponding  to  this  segrrtent. 
Thus,  the  output  specification  for  the  new  procedure  will  be 
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htadaUH  m)  <--  compute  htad(l)  < all{m)  . 

(This  procedure  tests  whether  the  head  of  / is  less  than  every  element  of  m.)  Then  we  can 
achieve  Coal  5, 

compute  head{l)  < all(tail{m)), 

by  a recursive  call  fieadallQ  tai/(m))  to  the  new  procedure. 


In  general,  suppose  we  are  developing  a program  whose  specifications 
are  of  the  form 

/(*)  <--  compute  P(x) 
where  Q(>c) , 

and  we  encounter  a subgoal 

Goal  B:  compute  R(l) , 

which  IS  an  instance  of  some  previously  generated  subgoal 
Goal  A:  compute  R(x) . 

We  assume  that  Goal  A is  some  ancestor  of  Coal  B other  than  the  top- 
level  goal.  The  procedure-formation  rule  proposes  that  we  introduce  a new 
procedure  g whose  output  description  is 

g{x)  <-•  compute  R{x) , 

so  that  we  can  achieve  Coal  B by  a recursive  call  g{t).  Then  we  set  aside 
the  original  derivation  for  Coal  A,  and  achieve  the  goal  by  a call  g{x)  to 
the  new  procedure. 

As  in  the  previous  section,  we  prefer  to  formulate  the  input 
specifications  for  the  new  procedure  g Incrementally,  rather  than  attempting 
to  express  this  specification  in  advance.  Again,  it  is  to  our  advantage  to 
have  as  few  conditions  as  possible  in  the  input  specification  for  g,  because 
each  of  these  conditions  must  be  checked  every  time  a call  to  g is 
introduced.  We  add  to  the  new  input  specification  only  those  conditions 
that  are  needed  in  the  course  of  the  derivation  of  g. 

Thus,  if  in  constructing  the  procedure  g we  fail  to  provi  some  condition 
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Six),  we  consider  adding  this  condition  to  the  input  specification  for  g.  ' 

However,  every  time  a call  giu)  to  the  new  procedure  has  been  introduced 
earlier  in  the  synthesis,  we  must  go  back  and  check  that  the  additional 
input  condition  S(u)  is  satisfied.  In  particular,  because  the  main  program  / 
now  contains  a call  gix)  to  achieve  Coal  A,  we  must  check  that  S(x)  holds 
when  this  call  is  executed  For  this  purpose,  we  may  use  the  input 
specifications  for  / or  any  of  the  case  assumptions  that  occur  in  the 
derivation  of  Goal  A. 

Goal  A,  compute  R(x),  now  becomes  the  top-level  goal  in  the 
construction  of  the  procedure  g.  Initially,  we  mirror  the  steps  of  the 
original  derivation;  that  is,  we  apply  in  the  new  derivation  the  same 
sequence  of  steps  that  we  applied  originally,  adding  conditions  to  the  input 
specification  of  g as  necessary.  Goal  B,  compute  R(r),  will  again  be 
introduced,  and  will  again  be  an  instance  of  Goal  A,  compute  R(x).  This 
time,  however.  Goal  A is  the  top-level  goal,  so  the  recursion-formation  rule 
can  be  applied  to  satisfy  Goal  B with  a recursive  call  git),  provided  that 
the  input  and  termination  conditions  are  satisfied.  This  input  condition  for 
such  a recursive  call  is  the  same  as  usual;  however,  the  termination 
condition  is  more  complex,  and  will  not  be  discussed  until  Section  3D. 

We  may  need  to  achieve  other  goals  to  complete  the  derivation  of  the 
main  prcKedure / and  the  subsidiary  procedure  g.  Of  course,  in  continuing 
these  derivations  we  may  introduce  still  more  subsidiary  procedures. 

Returning  to  our  allall  example,  recall  that  we  developed  a subgoal 
compute  headil)  < allitailim)) 

(Coal  5),  which  we  observed  to  be  an  Instance  of  its  ancestor  subgoal 
compute  htadil)  < allim) 

(Coal  2)  Therefore,  the  procedure-formation  rule  suggests  introducing  a new  procedure, 
htadall,  whose  output  specification  is 

headaim  m)  <--  compute  headil)  < allim) . 

The  partial  program  description  derived  from  Coal  2 is  set  aside;  this  goal  is  now  satisfied 
by  a call  headallU  m)  to  the  new  procedure.  Thus,  the  final  allall  program  Is 

allallU  m)  <-•  if  empfyil) 
then  true 


36 


Extensions  of  Recursion  Formation 


tlst  headallH  m)  and 
allallUailU)  m)  . 

We  have  yet  to  complete  the  construction  of  the  subsidiary  prcKedure  headall.  The  top- 
level  goal  for  the  procedure  is  Goal  2, 

compute  htad{l)  < aU(m)  . 

This  expression  is  not  well-formed  unless 

I and  m are  lists 
and  / is  not  empty. 

By  our  incremental  specification  technique,  we  consider  adding  these  conditions  to  the  input 
specification  for  htadall  Because  a call  htadaU(l  m)  has  already  been  introduced  in  the  main 
program  to  achieve  Coal  2.  we  must  check  that  these  conditions  are  satisfied  when  this  call  is 
made  However,  the  first  condition  is  the  input  specification  for  the  main  program,  and  the 
second  condition  holds  because  Goal  2 was  introduced  under  the  assumption  that  I is  not 
empty  Therefore,  these  conditions  may  safely  be  added  to  the  input  specification  for  headall. 

To  complete  the  derivation  of  the  htadall  procedure,  we  begin  by  mirroring  the  derivation 
leading  from  Goal  2 in  the  original  synthesis.  We  again  int  oduce  Goals  4 and  5.  Goal  5, 

compute  htad{l)  < all{tall{m)) , 

IS  again  an  instance  of  Goal  2, 

compute  headd)  < all(m)  . 

However,  this  time  Goal  2 is  the  top-level  goal,  and  the  recursion-formation  rule  can  now 
intrcxiuce  the  recursive  call  headalKl  (ail(m)).  (The  input  and  termination  conditions  for  this 
call  are  straightforward.)  The  complete  program  we  derive  is  thus 

allallU  m)  <--  if  emptyd) 
then  true 

tlst  headalld  m)  and 

ailalldaild)  m)  , 


where 


headalld  rn)  <»•  if  emptyim) 
then  true 

else  headd)  < head(m)  and 
headalld  tailim))  . 
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Another  Exampie 

Using  the  same  basic  principles  as  in  the  lessall  example,  but  employing  some  additional 
rules  for  the  sct-iheoretic  domain,  we  can  construct  a program  to  compute  the  Cartesian 
product  cart{s  l)  of  two  sets  s and  t.  The  specifications  for  this  program  are 

car((j  0 <“■  compute  { (xy) : x t j and  y € t } 
where  s and  ( are  sets. 

The  rules  for  sets  employed  in  this  synthesis  are  the  empty- set-formation  rule, 
lu  .false)  ->  1 } 

(where  { } is  the  empty  set),  the  union- formation  rule 
{u  : P{u)  or  Q(u)}  ->  (u  : P(u)}  u {u  : Q(u)} 

(where  o denotes  the  union  of  two  sets),  the  equality-elimination  rule 
{u  : u • t)  »>  {fj 

(where  u ard  t are  expressions  with  no  variables  in  common) . and  the  definition  of  the  member 
relation  « We  assume  that  the  empty  set  { },  the  functions  head(s)  and  tall(s),  the  union 
function  u.  and  the  notations  for  the  singleton  set  {s}  and  the  pair  (s  l)  are  among  the 
primitives  of  our  target  language 

We  will  be  very  brief.  In  deriving  the  program  from  the  specifications,  we  decompose  the 
output  specification  into  the  expression 

{ (x  y)  X • head(s)  and  y 1 1 ] u 
{ (x  y) : X « taiHs)  and  yet), 

corresponding  to  the  case  in  which  s is  nonempty.  The  second  subexpression, 

I (x  y) . X € tail(s)  and  yet), 
can  be  computed  by  a simple  recursive  call  cart(tail(s)  t). 

It  remains  to  compute  the  first  subexpression,  i.e.. 

Goal  A;  compute  ( (x  y) ; x • head(s)  and  y c r } . 

This  expression  decomposes  further,  yielding 
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{ (x  >) ; X - AtaMs)  and  y - /itadiO  ) u 
{ (x  j)) : X » head(s)  and  y c lal/(t) } 

in  thr  case  in  which  t is  nonempty.  The  first  subexpression, 

{ (x  ji)  : X - htad{s)  and  y - head(t)  } . 

reduces  directly  to  the  primitive  expression 

{ (head{s)  headil))  } . 

It  remains  to  compute  the  second  subexpression,  i.e., 

Goal  B:  compute  { (x  ^) : x • htad{s)  and  y t tail(t) } . 

Coal  B IS  an  instance  of  Coal  A;  therefore,  we  introduce  a new  procedure  carthead,  whose 
output  specification  is 

carthead(s  t)  <--  compute  { (x  ^) ; x - htad{s)  and  y s t } . 

(This  procedure  computes  the  Cartesian  product  of  the  singleton  set  {htad{s)]  and  t.)  To 
ensure  that  this  specification  is  well-formed,  we  are  forced  to  introduce  the  condition 

j and  t are  sets 

and  s is  not  empty 

as  the  input  specification  for  the  subsidiary  procedure. 

Then  Coal  A is  satisfied  by  a call  carlftead(s  t)  to  the  new  procedure,  while  Coal  B is 
satisfied  by  a recursive  call  carthead(s  tail(t)).  The  complete  Cartesian  product  program  is 

cart(s  t)  <--  if  empty(s) 
then  { } 

else  carthtad(s  t)  u 
carlUailU)  t))  , 


where 


cartheadis  t)  <--  if  emptyil) 
then  { ] 

else  {{headis)  head(t))]  i 
cartheadis  (aitU)) . 


The  Cartesian-product  example  is  derived  from  Darlington  [1975], 
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C.  The  Generalization  of  Subsidiary  Procedures 

In  our  discussion  of  subsidiary-procedure  formation,  we  introduced  a procedure  only  if  a 
subgoal  (Coal  B)  is  discovered  to  be  a precise  instance  of  a previously  generated  subgoal  (Coal 
A)  We  further  required  that  Coal  A be  a direct  ancestor  of  Coal  B (other  than  the  top-level 
goal)  However,  what  if  Coal  A is  not  actually  an  ancestor  of  Goal  B but  occurs  somewhere 
else  in  the  synthesis?  Or  what  if  Goal  B is  not  a precise  instance  of  Goal  A,  but  of  a somewhat 
more  general  expression?  In  fact,  the  techniques  we  have  already  introduced  extend  .naturally 
to  this  more  general  situation,  as  we  will  see  in  our  next  example.  This  example  will  also  serve 
to  illustrate  how  program-synthesis  techniques  can  be  applied  to  transform  an  already- 
constructed  program 

Suppose  we  are  given  the  following  program  reverse(l)  for  reversing  the  elements  of  a list  / : 

reversed)  <--  if  emptyd) 
then  nil 

else  append(reverse(taild)) 
list{headd)))  , 

where  nil  is  the  empty  list  and  appendQ^  /j)  is  the  program  for  appending  the  elements  of  two 
lists,  given  by 

appendd\  Ij)  <--  if  ernptyif) 
then  I2 

else  cons{headd\) 

• appendd<iild\)  Iz))  ■ 

This  reverse  program  is  not  very  efficient  because  its  execution  may  Involve  many  calls  to 
append,  moreover,  each  time  append  is  called  it  makes  a new  copy  of  Its  first  argument. 

Let  us  consider  the  given  reverse  program  to  be  the  specification  for  another  reverse 
program  Even  though  we  have  a program  to  compute  the  append  function,  let  us  treat 
append  as  a nonprimitive  construct.  Thus,  we  will  be  forced  to  transform  our  given  program 
into  an  equivalent  program  that  does  not  use  append.  Our  hope  is  that  the  resulting  program 
will  br  more  efficient 

We  assume  that  we  have  the  following  rules  that  explicate  the  append  construct: 

appendU\  Iz)  •>  Iz  if  f)  is  the  empty  list 

appendd\  Iz)  ->  cons{headd\) 

append(taild\)  Iz))  if  Iz  **  a nonempty  list, 


and 


appendfappenddf  Iz)  I3)  ->  appendd\  appendQz  I3))  • 
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Theie  rules  are  derived  from  the  apptnd  program  itself.  In  addition,  we  will  use  the  given 
rtvtrs*  program  as  a transformation  rule 

ttvtntil)  m>if  tmptfH) 
then  nil 

else  apptnd(rtveTst(taU(l)) 
liu{htad(l)))  . 

We  will  also  apply  several  rules  based  on  the  properties  of  list  structures. 

Our  top-level  goal  is 

Goal  1 : compute  if  empiy(l) 
then  nil 

else  append(r ever se(t 0x1(1)) 
listiheadd)))  . 

The  "nonprimitive’  construct  append  appears  m the  else  branch  of  the  goal.  Applying  the 
transformation  rules 

list{y^  y2  ...  Jn)  ->  coni(y,  lisKyj  . . . y„))  if  n i I 


and 


list(  ) m>  nil 

to  the  else  clause,  we  obtain 

Goal  2:  compute  append(reverse(tail(l)) 

consiheadd)  nil))  . 

Applying  to  the  subexpression  revet se(taild))  the  rule  for  reverse,  and  'pulling  out"'  the 
conditional  expression  using  the  rule 

fdf  P then  i|  else  s^)  ->  if  P then  f(s{)  else  f(s^  , 


we  obtain 

Goal  3 1 compute  if  emply(taild)) 

then  appendinil  cons(headd)  nil)) 
else  apptnd(app*nd(rtverse(taild<Uld))) 
llstiheaddalld)))) 
consiheadd)  nil))  . 


Applying  the  rule 
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A 

I 


appendU,  Ig)  ->  if  f,  is  the  empty  list 

to  the  lAen  clause,  anci  applying  the  rule 

apptnd{append{l\  /j)  ->  apptnd{l^  apptnd{l^  l^)) 

to  the  else  clause,  we  obtain 

Goal  4:  compute  if  empty(tail(l)) 

then  cons(AeadU)  nil) 

else  append{reverse{taU(tail{l))) 

append(list(head(tall{l))) 

cons{head{l)  nil)))  . 

Let  us  focus  our  attention  on  the  else  branch  of  this  goal. 

Goal  6:  compute  append{reverse(tail(tail{,l))) 

append(list(head{tail{l))) 

cons(Aead(l)  nil)))  . 

By  the  rules  for  list,  append,  and  cons,  this  reduces  to 

Goal  6:  compute  append{reverse(tail{tail(l))) 

cons{Aead{tail{l)) 

cons(head{l)  nil)))  . 

This  goal  IS  not  a precise  instance  of  the  higher-level  Coal  2, 

compute  append{reverse{tail{l)) 
consiheadil) 
nil))  , 

because  the  expression  cons(head{l)  nil)  in  Goal  6 coincides  with  the  constant  nil  in  Coal  2- 
However,  Coal  6 is  a precise  instance  of  the  somewhat  more  general  expression 

compute  append(reverse{tail(l)) 
cons(head(l) 
m))  , 

obtained  from  Coal  2 by  replacing  the  constant  nil  by  a new  variable  m. 

We  have  developed  a situation  in  which  a subgoal  is  a precise  Instance, 
not  of  the  previously  generated  subgoal,  but  of  a somewhat  more  general 
expression.  In  other  words,  we  have  found  that 
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Goal  B:  compute  R{b(x)) 
and  the  previously  generated 

Goal  Ai  compute  R{^x)) 
are  both  instances  of  the  more  general  expression 
compute  R{y) . 

(Note  that  we  do  not  need  to  assume  that  Coal  A is  actually  an  ancestor  of 
Coat  B,  or  even  that  both  appear  in  the  synthesis  of  the  same  procedure.) 

In  this  situation,  the  extended  procedure-formation  rule  proposes 
introducing  a new  subsidiary  procedure  g<y)  whose  purpose  is  to  achieve 
both  goals.  The  output  specification  for  g will  be 

g(y)  computa  R{y) . 

We  intend  to  achieve  Coal  A,  compute  R(a(x)),  by  a call  g(a(x)),  and  to 
achieve  Coal  B,  compute  R{b(x)).  by  a call  g{b(x)).  (In  the  special  case 
where  Coal  A is  already  the  top-level  goal  of  some  procedure  that  achieves 
it,  and  Coal  B is  a precise  instance  of  Coal  A,  there  is  of  course  no  need  to 
introduce  a new  procedure  to  achieve  Coal  A.) 

The  input  specification  for  the  new  procedure  g is  formed  Incrementally 
as  before.  The  top-level  goal  in  the  derivation  of  g is 

Goal  A (ganaralizcd):  computa  R{y) . 

In  constructing  the  subsidiary  program  g,  we  begin  by  attempting  to  mirror 
the  original  derivation  leading  from  Coal  A,  adding  conditions  to  the  input 
specification  as  necessary.  All  the  techniques  presented  previously  can  then 
be  applied  to  complete  the  derivation  of  g. 

Returning  to  our  example,  recall  that  the  extended  procedure-formation  rule  proposer 
introducing  a new  subsidiary  procedure  reversegenU  m)  to  compute  the  more  general  expression 
Thus,  the  output  specification  for  revenegen  Is 

reversegenU  m)  <—  computa  append(reverse{tallU)) 

consiheadU) 

m)) . 

(Intuitively,  the  rtvtrstgenU  m)  reverses  a nonempty  list  / and  appends  the  result  to  m .) 
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Now,  Goal  2 in  the  derivation  of  the  main  program  is  achieved  by  a call  reversegenU  nil)  to 
the  subsidiary  procedure.  The  final  reverse  program  is  then 

reversed)  <--  if  empty(l) 
then  nil 

else  reversegend  nil)  . 

It  remains  to  complete  the  derivation  of  reversegen.  The  top-level  goal  for  this  derivation  is 
obtained  directly  from  the  output  specification: 

Goal  2 (generalized):  compute  append{reverse{taild)) 

cons{headd) 
m))  , 

To  ensure  that  this  expression  is  well-formed,  we  add  the  conditions 

/ and  m are  lists 
and  I IS  nonempty 

incrementally  to  the  input  specification  for  the  reversegen  procedure.  We  then  attempt  to 
mirror  the  original  derivation  leading  from  Coal  2.  We  succeed  in  applying  the  same  rules  as 
before,  ultimately  obtaining 

Goal  6 (genaralized):  compute  appenddeverse(taild<iW)) 

consiheaddaild)) 
cons(headd) 
m)))  . 

This  time,  the  generalized  Goal  6 is  indeed  an  instance  of  the  generalized  Goal  2,  obtained  by 
replacing  I with  laild)  and  m with  cons(headd)  m).  Therefore,  we  can  achieve  the  new  Goal  6 
by  a recursive  call  reversegendaild)  cons{headd)  m))  to  the  subsidiary  procedure.  The  final 
reverse  program  we  obtain  is  thus 

reversed)  <--  if  empty(l) 
then  nil 

else  reversegend  nil) 

where 

reversegend  m)  <--  if  empty(taild)) 

then  cons(headd)  m) 
else  reversegendaild) 

cons(headd)  tn))  . 
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This  is  a better  revtrst  program  than  the  one  we  were  originally  given.  Not  only  has  the 
expensive  append  program  been  eliminated,  but  by  good  fortune  the  new  procedure  reversegen 
we  have  obtained  is  of  a special  form,  for  which  the  recursion  can  be  Implemented  efficiently 
without  the  use  of  a stack. 


The  reverse  example  follows  Burstall  and  Darlington  [1977].  Their  system 
does  not  perform  the  generalization  automatically. 


D.  Systems  of  Mutually  Recursive  Procedures 

In  the  above  examples  we  have  used  the  usual  techniques  for  showing  the  termination  of 
the  programs  and  procedures  we  construct.  However,  certain  situations  arise  in  introducing 
subsidiary  procedures  that  require  this  technique  to  be  strengthened.  In  particular,  we  can 
form  systems  of  mutually  recursive  procedures,  i.e.  procedures  each  of  which  may  contain  calls  to 
the  others  Let  us  see  how  such  a system  can  emerge. 

Suppose  that  one  subgoal  in  the  derivation  of  a subsidiary  procedure  g is  achieved  by  a call 
to  the  mam  program  /.  Then  the  program  / will  be  expressed  In  terms  of  a call  to  the 
procedure  g, 

f{x)  <—  ...  giu)  ...  , 

while  g will  be  expressed  in  terms  of  a call  to  the  main  program  /, 

g(y)  <..  ...  J{v)  ...  . 

Such  a system  of  mutually  recursive  procedures  can  fail  to  terminate,  say  if  /calls  g,  g calls 
/,  / calls  g again,  and  so  on  indefinitely.  The  naive  approach  for  showing  the  termination  of 
such  a system  is  to  show  that  all  the  inputs  and  arguments  belong  to  some  well-founded  set  W , 
and  that 

u < X and  v < y 

under  the  ordering  < of  IV . However,  there  are  systems  whose  termination  cannot  be  shown  by 
this  approach,  for  example,  if  u is  x itself,  then  no  well-founded  ordering  will  allow  us  to  show 
u < X.  Furthermore,  in  some  systems,  / and  g may  apply  to  different  domains; / may  apply  to 
lisu,  say,  and  g may  apply  to  numbers;  in  such  a case.  It  may  be  difficult  to  construct  a single 
well-founded  set  that  contains  the  arguments  of  both  / and  g. 
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To  show  the  termination  of  a system  f\,  /j,  f^,  ••  of  mutually  recursive  procedures, 
we  resort  to  a more  general  method:  We  find  (as  before)  a single  well-founded  set  W with  an 
ordering  < . In  addition,  we  find  a termination  function  corresponding  to  each  procedure/^  , 

such  that  T,-  maps  the  arguments  of  fi  Into  IV  and  such  that,  whenever  a caller)  occurs  in  the 
execution  of  the  procedure /,(x),  we  can  establish  the  termination  condition 

Tft)  < r,(x) . 

This  suffices  to  prove  the  termination  of  the  system,  because  If  there  were  a computation 
containing  an  infinite  sequence  of  calls 

fa^^a^  ' • fc^^c^  • ■ ■ ■ ’ 

the  corresponding  sequence 

7-^).  W.  W,  ... 

of  elements  of  IV  would  be  infinitely  decreasing,  contradicting  the  definition  of  a well-founded 
set 


To  illustrate  this  method,  we  will  briefly  consider  this  simple  example  of  a system  of 
mutually  recursive  procedures  to  compute  the  gcd  of  two  nonnegative  integers  x and  y : 


gcdoix  y)  <—  1/  X • 0 
then  y 

else  gcd,{x  y) 

gcd,(xy)<.-  ifyix 

then  gcrfjfx  y) 
else  gcdyix  y) 

gcd2(xy)<—  gcdy(xy-x) 


gcd2{xy)<—  gcdoiyx). 


For  this  example,  the  naive  approach  is  to  show  that  the  inputs  (x  y)  and  the  arguments  of 
each  procedure  call  belong  to  the  well-founded  set  IV  of  pairs  of  nonnegative  integers,  and  that 
the  arguments  of  each  procedure  call  are  less  than  its  inputs  under  some  well-founded  ordering, 
such  as  the  lexicographic  ordering  This  approach  fails  here  because,  for  Instance,  the  main 
program  gcdffx  y)  executes  a procedure  call  gC(f|(x  y)  whose  arguments  are  the  same  as  the 
inputs 
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It  suffices,  however,  to  take  IV  to  be  the  set  of  triples  of  nonnegative  integers,  under  the 
lexicographic  ordering  <.  Corresponding  to  each  procedure  ged^  we  have  a termination 

function  T^  : 

To(x  y)  •(xy2)  , 

Tx(xy)  - (xjf  I)  , 

T^xy)  • (xyO)  , and 
- (x  0)  . 

Now,  each  time  a procedure  call  gedj^u  v)  is  executed  within  a procedure  ged^x  y)  we  need  to 
show  the  termination  condition 

T^xiv)  < r,(x  y) . 

For  example,  because  ged^x  y)  calls  gcd,(x  y)  when  x is  not  zero,  we  have  to  show 
(x  I)  < (x  2) , 

which  IS  clearly  true  under  the  lexicographic  ordering.  Because  ged^x  y)  calls  ged^/y  x)  when  y 
IS  less  than  x , we  have  to  show 

{y  X 2)  <{xy0) , 

which  also  holds  under  the  lexicographic  ordering  since  y < x . 
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4.  8TRUCTURE-CHANOINO  PROGRAMS 
A.  Straight-Line  Programs 

The  programs  we  have  been  developing  up  to  now  have  been  striuture-maintaining 
programs:  they  do  not  alter  the  value  of  any  variable  or  change  the  configuration  of  any  data 
structure  Thus,  any  condition  that  is  true  before  executing  such  a program  will  also  be  true 
afterwards  In  this  section,  we  extend  the  techniques  we  have  already  introduced  to  permit  the 
construction  of  structure-changing  programs;  these  programs  can  reset  the  values  of  variables, 
change  the  contents  of  an  array,  or  alter  the  structure  of  a list  or  other  data  object.  (Commonly, 
such  changes  are  called  side  effects,  this  term  has  the  unfortunate  connotation  that  the  effects 
are  undesirable,  rather  like  a headache.)  In  executing  such  a program,  a condition  that  was 
previously  false  can  be  made  true,  and  the  opposite. 

For  example,  a program  that  merely  outputs  the  maximum  element  of  an  array  is  a 
structure-maintaining  program;  its  execution  does  not  change  the  contents  of  the  array.  On  the 
other  hand,  a program  to  sort  an  array  in  place  is  a structure-changing  program,  because  the 
contents  of  the  array  may  be  changed. 

The  basic  principles  of  program  construction  introduced  earlier  (such  as  conditional 
formation,  recursion  formation,  generalization,  and  procedure  formation)  extend  naturally  to  the 
development  of  structure-changing  programs.  In  addition,  we  will  need  some  basic  principles 
that  specifically  pertain  to  this  new  class  of  programs. 

To  express  programming  problems  that  require  structure  changing,  we  need  to  introduce 
new  constructs  into  our  specification  language.  To  express  programs  that  solve  such  problems, 
we  need  to  Introduce  new  primitive  statements  Into  our  target  language. 

To  the  specification  language  we  add  the  new  construct 
achieve  P , 

where  P is  some  condition  The  meaning  of  this  construct  is  that  the  corresponding  program 
segment  is  to  cause  condition  P to  become  true.  (Thus,  achieve  x - 2 can  yield  a program 
segment  that  sets  x to  be  2.) 

We  also  extend  our  target  language  to  include  assignment  statements,  such  as  variable 
assignments,  e g., 

u *-  t , 


array  assignments,  e g.. 
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a[»] »-  t , 

and  list  assignments,  e g., 

headd)  *-  t and  tail{l)  *- 1 . 

The  effect  of  these  statements  is  to  change  the  value  of  the  variable  u,  the  contents  of  the 
array  element  a[i).  and  the  head  and  tail  of  the  list  I,  respectively. 

We  will  Introduce  other  specification  and  target-language  constructs  in  the  context  of 
specific  examples 

Let  us  introduce  rules  that  explicate  the  achieve  construct  and  relate  it  to  the  assignment 
statements  For  instance: 

• The  achieve- elimination  rule 

achieve  P ->  prove  P . 

This  rule  expresses  that  to  achieve  some  condition  P,  it  suffices  to  prove  that  P is  already  true. 
The  rule  is  generally  applied  in  conjunction  with 

• The  prove-elimination  rule 

prove  true  ->  A , 

where  A represents  the  empty  program  segment.  Together,  these  rules  allow  us  to  remove  from 
the  program  description  any  subexpression  of  form  achieve  P,  where  P can  be  proven  to  be 
true.  Because  prove  is  a nonprimitive  construct,  a program  segment  containing  a 
subexpression  prove  P must  be  transformed  until  the  subexpression  is  eliminated,  i.e.,  until  we 
prove  that  P holds  when  control  passes  through  the  corresponding  point. 

• The  variable-assignment  formation  rule 

achieve  P(u)  ->  prove  P{t) 

u *-  t for  some  t 

where  u is  a variable  and  t is  an  expression  This  rule  expresses  that  if  the  condition  P(f)  is 
true,  we  can  achieve  a condition  of  form  P(u)  by  the  variable  assignment  u *-  t. 

Let  us  illustrate  how  these  rules  can  be  applied  to  construct  a program  to  achieve  x - 2. 
The  specifications  for  the  program  are 


maketwo(x)  <--  achieva  x - 2 . 
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Our  top-level  goal  is  therefore 

Goal  1 i achieve  x - 2 . 

Two  of  the  above  rules  match  this  goal.  The  achieve-elimination  rule  transforms  this  goal  Into 
the  subgoal 

Goal  2i  prove  x - 2 , 

which  fails  The  variable-assignment  formation  rule,  on  the  other  hand,  leads  to  the  subgoal 

Goal  3:  prove  t • 2 

X *- 1 for  some  t . 

Applying  the  rule  for  equality, 

u - u ->  (rue  , 

forces  us  to  take  t to  be  2 itself;  we  obtain 

Goal  4:  prove  true 
x-2. 

Finally,  the  prove-elimination  rule  yields  the  ultimate  program 
makeiwo(x)  <--  x ♦-  2 . 


B.  Conditional  Programs 

Let  us  illustrate  how  the  conditional-formation  rule  extends  to  allow  the  Introduction  of  tests 
into  structure-changing  programs.  For  this  purpose,  we  will  construct  a program  sort2(x  y)  to 
sort  the  values  of  two  variables  x and  y.  We  will  assume  that  the  target  language  contains  the 
new  instruction  tnttrchangtix  y),  which  has  the  effect  of  exchanging  the  values  of  the  variables 
X and  y This  instruction  is  deKribed  by  the  interchange  rule 

achlav*  P(u  v)  •>  prove  P(v  u) 

interchangeiu  v) , 


where  u and  v are  variables. 


The  output  specification  for  the  sort2  program  is 
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S0Tt2(x  y)  <--  achieve  x iy  and  perm{(xQ  y^Y^x  y)) 

Here,  perm({xQ  >))  means  that  the  values  of  x and  y are  a permutation  of  their  original 
values  Xq  and  yo  [In  the  following,  we  will  abbreviate  this  condition  as  perm{{x  31)).]  This 
condition  is  necessary  because,  were  it  omitted,  the  sorr2  program  could  achieve  x i y simply  by 
resetting  x and  y,  say  to  I and  2,  respectively.  However,  the  output  specification  for  this 
program  is  to  achieve  two  conditions  at  the  same  time;  such  goals  require  special  treatment  and 
will  not  be  discussed  until  the  next  section  The  purpose  of  this  section  Is  merely  to  illustrate 
conditional  formation  in  structure-changing  programs  Consequently,  we  will  ignore  the 
permutation  property  and  pretend  that  the  output  specification  has  only  the  one  condition, 
achieve  x < y.  We  will  ensure  that  the  permutation  property  is  preserved  by  temporarily 
allowing  intercfiangeix  y)  to  be  the  only  structure-changing  primitive  in  our  target  language. 

Our  top-level  goal  is  therefore 

Goal  1 : achieve  x s y . 

The  achieve-elimination  rule, 

achieve  P ->  prove  P , 

transforms  this  goal  to  form  the  subgoal 

Goal  2:  prove  x S y . 

We  can  neither  prove  nor  disprove  x s y — x and  y are  inputs  — so  we  Introduce  a case 
analysis  based  on  this  condition. 

Case  y < X : Here,  we  cannot  achieve  Goal  2,  so  we  seek  alternate  ways  to  achieve  Goal 
I Our  interchange  rule, 

achieve  P(u  v)  ->  prove  P(v  u) 

inttrehangeiu  v) , 

causes  us  to  transform  Coal  I into 

Goal  3:  prove  y S x 

inlerchangeix  y)  . 

However,  we  are  assuming  that  y < x in  this  case  Therefore,  the  subexpression  prove  y s x is 

eliminated  by  applying  the  rule  T 


u s ti  ->  trut  if  u < ti , 
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followed  by  the  prove-elimination  rule.  Consequently,  we  generate  the  program  segment 
interchange(x  y) 

in  this  case.  It  ■'cmains  to  consider  the  alternate  case. 

Case  X s y : Here,  Goal  2,  prove  x s jr,  is  achieved  by  the  prove-elimination  rule,  and 
we  arc  left  with  the  empty  program  segment  A 

Our  final  program  is  therefore 

sort2{x  y)  <-•  if  y < x 

thru  interchangeix  y) 
else  A 

or.  equivalently, 

sort2{x  y)  <--  if  y < x 

then  interchangeix  y)  . 

C.  The  Weakest-Precondition  Operator 

In  formulating  the  specifications  for  the  sort2  program  In  the  previous  section,  we  avoided 
including  in  the  output  specification  the  condition  ptrm((x  y)},  otherwise,  the  top-level  goal 
would  have  been 

i 

achieve  x iy  and  ptrn{{x  y)) . 

Special  difficulties  arise  In  approaching  a simultaneous- goal  problem,  l.e.,  a goal  of  the  form 

« 

achieve  Pj  and  , 

where  P,  and  P2  are  to  hold  simultaneously.  We  cannot  always  decompose  such  a goal  into  a 
sequence  of  two  goals 

achieve  P^ 
achieve  Pj  . 


achieve  P; 
achieve  P^  , 


or 
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because  in  the  course  of  making  the  second  condition  true  we  may  very  well  make  the  first 
false  For  instance,  in  the  Jorf2  problem,  we  can  achieve  * s 31  by  setting  x to  1 and  y to  2,  and 
we  can  achieve  ptrm({x  y))  by  setting  x and  y to  their  original  values,  but  no  concatenation  of 
these  two  programs  will  sort  x and  y . 

To  handle  such  simultaneous-goal  problems  properly,  we  need  to  analyze  what  effect  a 
given  program  segment  has  on  the  truth  of  a given  condition.  For  this  purpose,  we  define  the 
concept  of  the  weaken  precondition,  we  will  then  use  this  concept  to  formulate  a program- 
modification  technique  that  will  serve  as  the  basis  for  our  simultaneous- goal  principle. 

If  5 IS  a program  segment  and  P is  a condition,  we  define  the  weakest  precondition  wp{S  P) 
to  be  the  condition  P'  such  that 

P'  IS  true  before  executing  5 
if  and  only  if 
P IS  true  afterwards. 

(We  will  assume  throughout  that  S terminates.)  We  will  also  call  tup(S  P)  the  result  of  passing 
P back  over  S Thus,  the  weakest  precondition  for  the  execution  of  the  program  segment 
X *-  x+  I to  achieve  the  condition  x s 2 is  x-f  1 s 2,  i e.,  x i 1 In  other  words, 

wp(  x*-x+l  x22)isx2l. 

We  can  represent  the  properties  of  the  weakest-precondition  operator  by  transformation 
rules.  Some  of  these  rules  tell  how  to  compute  the  weakest  precondition  for  particular 
specification-  or  target-language  constructs: 

wp(  A P ) ~>  P 

wp(  u «-  t P(u) ) •>  P(t) 

wpi  intercbangeiu  v)  P{u  0) ) •>  P(v  u) 

wp(  if  q then  5|  else  Sj  P ) ->  {if  q then  wp{5f  P))  and 

{if  not  q then  wp{52  P)) 

wpi  if  q then  5 P )•>  {if  q then  wp{5  P))  and 
{if  not  q then  P) 

wp{SyS2  P)^>wp{S\  wp(S2  P) ) 

wp{  achlovo  Q P ) ■>  true  if  Q implies  P . 
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The  weakest-precondition  rule  for  the  recursion  construct  does  not  tell  us  how  to  compute 
the  weakest  precondition,  but  only  how  to  prove  by  mathematical  induction  that  a given 
condition  Is  indeed  the  weakest  precondition  for  a recursive  call.  Suppose  that/^s)  is  a call  to  a 
procedure 

f{x)  <-  B(x) , 

and  that  < is  a well-founded  ordering.  Then,  for  any  condition  P{x) , we  have 
wpiJKs)  P(s))~P'(s) 
if  we  can  prove 

uipiBM  P(x))  - P'(x) 
under  the  inductive  assumption  that 
ivp(J(t)  PU)).P'{t) 

for  any  t such  that  t < x.  (Often,  < is  taken  to  be  the  well-founded  ordering  used  to  prove  the 
termination  of  /.) 

In  addition  to  rules  that  give  the  weakest  prec  editions  for  the  various  programming- 
language  constructs,  there  are  rules  for  computing  the  weakest  preconditions  for  specific 
conditions  For  example, 

wp(S  trut)  ->  trut  , 

wp{S  foist)  ->  foist  , 

wpiS  P\  and  P^  ->  wp(S  P f)  ond  wp{5  Pif) , 
wpiS  P\  or  Pff)  ->  01^(5  P\)or  wp(S  Pj)  , and 
wp{S  not  P)  ->  not  wp{S  P)  . 

When  a new  construct  is  defined  in  terms  of  other  constructs,  we  can  often  deduce  the 
weakest-precondition  rule  for  the  new  construct.  For  example,  Jorf2(u  v)  is  the  program 

if  V < u 

thtn  Inttrchongtlu  v)  . 


Therefore, 


0 

I 
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wp  ( sortTiu  v)  P(u  v) ) 

• wp  ( if  V < u t/ien  interchange{u  v)  P(u  v) ) 

• if  V < u thtn  VDp(inttTchange(u.  v)  P{u  v))  and 
ifuiv  thtn  P(u  v) 

• if  V < u then  P(v  u)  and 
if  u i V then  P(u  v) . 

We  thus  obtain  the  sort2  rule 


wp(  sort2(u  v)  P(u  v) ) {if  V < u thtn  P(v  u))  and 

(If  u iv  thtn  P(u  v)) . 

On  the  other  hand,  if  we  introduce  a new  construct  into  our  specification  or  target  language 
that  is  not  expressed  in  terms  of  other  constructs,  we  must  also  provide  weakest-precondition 
rules  for  the  new  construct.  For  example,  we  have  used  the  construct  ptrm(l)  to  denote  that  the 
values  of  the  variables  in  a list  I are  a permutation  of  their  original  values;  we  must  therefore 
introduce  rules  such  as 

wp(  interchangeiu  v)  ptrm(l) ) ->  perrnQ)  if  u and  v belong  to  / . 

In  other  words,  interchanging  the  values  of  two  of  the  variables  of  the  list  does  not  affect  the 
permutation  property.  Similarly,  we  will  introduce  the  construct  only  I changed  to  denote  that 
no  variables  other  than  those  in  / are  changed  by  the  program  segment;  we  will  also  Introduce 
the  corresponding  rule 

topi  u *•  t only  I changed  ) ->  only  I changed  if  u 1 1 . 

The  weakest-precondition  operator  is  used  to  express  many  transformation  rules  that 
manipulate  structure-changing  programs  Two  regression  rules  are  obtained  directly  from  the 
deftntcion  of  the  weakest  precondition: 


S 

prove  P 


■ > prove  wp{S  P) 
S 


and 


S ■>  achieve  tup(S  P) 

achieve  P 5 . 


That  Is,  to  prove  or  achieve  a condition  P after  a program  segment  5,  one  may  just  as  well 
prove  or  achieve  the  weakest  precondition  wp(S  P)  before  S. 


« 
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We  have  two  additional  rules  for  pushing  goals  back  into  conditional  expreuions; 


«/  q 

then  S| 
else  S2) 
achieve  P 


ifq 

then  S I 

achieve  P 
else  $2 

achieve  P 


and  (consequently) 


{if  q 
then  S |) 
achieve  P 


then  S I 

achieve  P 
else  achieve  P . 


Let  us  see  how  these  concepts  can  be  applied  to  obtain  a systematic  program-rrHxlifIcation 
technique,  which  will  eventually  be  used  in  the  simultaneous-goal  rule. 


The  weakest -precondition  operator  of  Dijkstra  [1975]  was  motivated  by 
the  program-verification  technique  of  Fioyd  [1967]  and  Hoar*  [1969]. 


D.  A Program-Medifioation  Technique 

Imagine  that  we  have  a program  segment  5 that  is  a concatenation  S1S2  of  two  instructions. 
Suppose  we  wish  to  alter  5 to  achieve  some  new  condition  P.  The  most  straightforward 
approach  is  to  add  new  instructions  to  the  end  of  S that  achieve  the  new  condition;  we  may 
describe  the  desired  modification  as 

51 
$2 

achieve  P . 

However,  according  to  the  regression  rule  of  the  previous  section,  we  may  Just  as  well  add  new 
instructions  to  achieve  tssp{S2  P)  before  52;  i.e.,  we  can  pass  P back  over  Si,  yielding 

5| 

achieve  iup(S2  P) 

52 
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Similarly,  we  can  pass  wpiS^  P)  back  over  5|  : 
achieve  up{Sf  P)) 

Sj 

T hus,  we  can  make  modifications  at  any  point  in  S to  achieve  the  desired  condition. 

For  example,  suppose  that  5 is  a program  segment 

y -y+l 

and  that  we  want  to  modify  S to  achieve  the  relation  y ^ Z,  this  modification  tuk  may  be 

expressed  as 

y t-  X 
y -y+l 

achieve  y z 2 . 

We  can  certainly  achieve  the  new  condition  by  adding  an  instruction  (e.g.,  y «-  2)  to  the  end  of 
the  program.  But,  by  the  regression  rule,  we  can  also  transform  the  above  task  into 

y-x 

achieve  y 2 1 
y -y+l 

and  then  into 

achieve  x i I 
y •-  X 
y - y+ 1 . 

[In  the  first  transformation,  we  relied  on  the  fact  that  wp(  y *-  y*l  y22)isy4l22,  i.e.,  y it  1 ; 
the  second  step  relied  on  the  fact  that  wp(  y«-x  y i I)isx2  1.]  Thus,  we  can  also  perform 
the  required  modification  by  adding  instructions  In  the  middle  of  the  program  (e.g.,  y «-  I)  or  at 
the  beginning  (eg.,  x ♦-  J) . 

Of  course,  a program  segment  modified  by  the  above  technique  may  no  longer  achieve  the 
purpose  for  which  it  was  originally  intended.  Suppose  that  a program  segment  5 was  originally 
intended  to  achieve  some  condition  P,,  and  we  want  to  modify  5 to  achieve  a new  condition  P2 
as  well  as  the  original  condition  P|.  To  ensure  that  the  modified  program  still  achieves  its 
original  purpose,  we  protect  P\  at  the  end  of  5 during  the  modification  process.  This 
modification  task  is  denoted  by 
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5 

achieve 
protect  P|  , 

The  purpose  of  the  protection  condition  protect  P,  is  to  block  any  noodification  that  does  not 
allow  us  subsequently  to  prove  the  protected  condition  P,.  Let  us  see  how  such  a protection 
condition  is  checked 

Returning  to  the  previous  example,  suppose  in  rrKxlifying  the  program  segment 

y *-  X 

51 -31+ 1 

to  achieve  the  new  condition  y i 2.  we  want  to  protect  the  condition  x < y that  the  program 
originally  achieved  Our  task  can  thus  be  described  as 

Goal  1 1 ^ X 

y-y+l 
achlava  y i 2 
protect  X < y . 

We  have  seen  that  we  can  achieve  the  desired  condition  y i 2 by  introducing  statements  at  the 
end  (eg.,  y - 2).  the  middle  (eg.,  y •-  1),  or  the  beginning  (eg.,  x «-  I)  of  the  program.  To  check 
the  protection  condition  for  a proposed  mcxllfication,  we  try  to  prove  that  the  protected 
condition  still  holds  in  the  modified  program.  Thus,  to  see  whether  introducing  y «-  2 at  the 
end  of  the  program  violates  the  protected  condition,  we  establish  the  subgoal 

Goal  2:  y *-  x 
y-y4l 
y ► 2 

prove  X < y . 

This  means  that  we  must  prove  that  x < y holds  after  the  execution  of  the  modified  program. 

In  fact,  we  fail  to  prove  this  condition,  10  the  proposed  modification  is  rejected.  Similarly, 
we  cannot  achieve  the  desired  condition  by  Inserting  the  statement  y *-  1 in  the  middle  of  the 
program,  because  we  fail  to  establish  the  corresponding  subgoal 

Goal  3:  y «-  x 
y - I 
y V y+l 
prove  X < y . 
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However,  the  third  proposed  modification,  to  injert  * <-  J at  the  beginning  of  the  program,  does 
maintain  the  protected  condition: 

Goal  4:  x <-  I 
y X 
y*-y*l 
prove  X < y . 

Let  us  see  in  more  detail  how  such  a proof  is  conducted. 

Applying  the  regression  rule 

5 » prova  wp(S  P) 

prova  P S , 

we  develop  the  tubgoal 

Goal  6:  x «-  I 
y^x 

prova  wpi  y *■  y*\  x < y) 

31-y+l  . 

The  weakest-precondition  rule  for  assignment  statements, 

wp{  u *-  t P{u) ) ->  Pit) , 

eliminates  the  weakest-precondition  operator: 

Goal  6:  x •-  I 
y *-  X 

prova  X < jK  I 
y^y*\  . 

Again  applying  the  regression  and  assignment  rules,  we  obtain 

Goal  7)  X «-  I 

prova  X < x-f  I 
y^x 

The  condition  prova  x < x-f  I can  now  be  established  by  the  rule 


u < U4 1 •>  irut  if  u IS  a number. 
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Having  verified  the  protection  condition,  we  obtain  the  program 

X *-  1 

y-x 

> + > . 

which  achieves  both  the  original  condition  x <y  and  the  additional  condition  yz2. 

The  previous  discussion  neglected  the  strategic  aspects  of  our  program  modification 
technique.  How  do  we  divide  our  time  between  altering  the  program  to  achieve  a new 
condition  Pj  and  ensuring  that  a protected  condition  P|  Is  still  achieved?  The  most 
adventurous  strategy  is  first  to  complete  the  modification  necessary  to  achieve  P2,  and  then  to 
check  that  P|  still  holds.  This  can  be  wasteful,  however,  because  we  may  need  to  do  a lot  of 
work  modifying  the  program  to  achieve  Pj  before  we  discover  that  P|  is  not  achieved  by  the 
modified  program.  A more  conservative  strategy  Is  to  check  that  the  protection  conditions  are 
maintained  each  time  a new  instruction  is  inserted  during  the  modification  process;  thus  a 
proposed  modification  that  does  not  achieve  P]  may  be  rejected  quite  early.  For  example,  if  P| 
is  the  permutation  property  ptrmU),  that  the  values  of  the  variables  in  the  list  I are  to  be  a 
permutation  of  their  original  values,  we  will  admit  modifications  that  interchange  the  values  of 
variables  in  /,  but  reject  modifications  that  attempt  to  assign  new  values  to  these  variables. 
This  conservative  strategy  is  adhered  to  by  our  implemented  system;  it  is  a bit  too  restrictive, 
because  a modification  that  satisfies  the  protection  condition  only  at  the  final  stage  may  be 
rejected  if  its  protection  condition  is  checked  prematurely. 

The  above  modification  technique  allows  us  to  insert  new  Instructions  into  the  program 
segment,  but  not  to  alter  or  delete  any  of  the  instructions  that  are  already  there.  Such 
modifications  may  sometimes  be  necessary,  but  they  are  beyond  the  scope  of  our  technique. 


The  protection  concept  was  used  by  Sussman  [1975]  as  an  approach  to 
plan  formation  by  the  successive  debugging  of  nearly  correct  plans. 


E.  The  SimuU»n«ous-Ooal  Principle 

We  have  remarked  that  when  faced  with  a simultaneous-goal  problem 
achieve  P,  and  Pj  , 

we  cannot  decompose  the  goal  into  the  linear  sequence 

achieve  P, 
achlova  Pg 
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because,  in  the  course  of  making  Pj  true,  we  may  be  making  P\  false.  For  the  same  reason,  It 
IS  not  enough  to  reverie  the  order  in  which  the  goals  are  achieved.  However,  the  program 
modification  technique  o.  the  previous  section  gives  us  a way  of  solving  such  a problem.  To 
apply  this  technique,  we  first  construct  a program  that  achieves  P\-,  we  then  modify  this 
program  to  achieve  P2  while  protecting  P\.  The  simultaneous- goal  rule  that  represents  this 
approach  is 

* 

achieve  P|  and  P2  ->  achieve  Pj 
achieve  P; 
protect  P|  . 

(Of  course,  the  roles  of  P|  and  P2  can  be  reversed.)  This  rule  extends  naturally  to  the  more 
general  problem  of  achieving  many  conditions  simultaneously;  we  consider  P^  to  be  one  of  the 
conditions,  and  P;  to  be  the  conjunction  of  all  the  others. 

The  simultaneous-goal  principle  does  not  dictate  which  condition  we  attempt  to  achieve 
first.  In  general,  if  we  discover  that  one  of  the  conditions  is  already  true,  we  prefer  to  "achieve” 
that  condition  first,  protect  it,  and  go  on  to  achieve  the  others.  Furthermore,  we  may  have  rules 
for  specific  subject  domains  that  cause  these  conditions  to  be  reordered. 

Let  us  see  how  the  simultaneous-goal  rule  applies  to  a new  sorting  problem;  this  time  we 
wish  to  sort  three  variables  x,  y,  and  z.  The  problem  can  be  specified  by 

sortS(x  y z)  <--  achieve  x i y and  y i z and  perm((x  y z)) 

whore  x,  y,  and  z are  variables  with  numerical  values. 

We  will  introduce  the  program  sort2(u  v),  which  we  constructed  in  the  previous  section,  as  a 
primitive  in  the  target  language.  Because  the  sort2  program  was  constructed  to  achieve  the 
condition  u s v,  we  can  include  the  sort2-formaUon  rule 

achiovo  u i v ->  sort2{u  v) 

in  our  set  of  transformation  rules.  Because  sort2{u  v)  was  specified  to  maintain  the  condition 
permdu  v)),  we  can  add  the  sort2-p*rm  rule 

wp{  sort2iu  v)  perm(l) ) ->  permit)  If  u and  v belong  to  I . 

The  top-level  goal  for  the  sortS  derivation  is 

Goal  1 1 achiovo  x s y and  y s z and  permiix  y z)) . 

We  apply  the  simultaneous-goal  principle;  because  the  condition  permiix  y z))  is  already  true,  it 
IS  the  first  to  be  "achieved": 
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Goal  2:  achlava  y z)) 

achlava  x i j and  y s z 
protact  permUx  y z)) . 

Because  p€rm((x  y z))  is  true  initially,  we  can  eliminate  the  first  task  achlava  perm^x  y z))  by 
applying  first  the  achieve-elimination  rule 

achieve  P •>  prove  P , 

and  later  the  prove-elimination  rule 

prove  true  •>  A . 

We  obtain 

Goal  3;  achlava  x i y and  y i z 
protect  permdx  y z)) . 

The  first  task,  achiave  x < y and  y s z,  is  another  simultaneous-goal  problem;  we  again 
apply  the  simultaneous-goal  rule,  arbitrarily  attempting  to  achieve  the  condition  x i y first. 

Goal  4i  achlava  xs^ 
achlava  y s z 
protect  X i y 
protect  perm((x  y z)) . 

Applying  the  new  sorr2-formation  rule 

achieve  u s v •>  sort2(u  v) 

to  the  first  task,  achieve  x s y,  yields 

Goal  6i  Jort2(x  y) 

achieve  y i z 
protect  X iy 
protect  perm({x  y z)) . 

We  first  attempt  to  apply  the  tame  rule  to  the  second  task,  achieve  yit,  yielding 

Goal  Si  sort%x  y) 
tortiiy  z) 
protect  X s y 
protect  perrndx  y z)) . 
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However,  in  executing  the  instruction  soTt2(y  z)  we  may  violate  the  protected  condition  x s y . 
(In  particular,  if  z was  initially  the  smallest  of  the  three  values,  then  sorting  j|  and  z makes  y the 
smallest:  x and  y will  now  be  out  of  order.)  Therefore,  we  are  forced  to  backtrack  and  consider 
alternate  means  for  achieving  Goal  5. 

By  applying  the  regression  rule 

S ->  achieve  wp(5  P) 

achieve  P S , 

we  derive 

Goal  7:  achieve  wp{  sort2{x  y)  y i z) 
sort2ix  y) 
protect  X i y 
protect  perm{[x  y z)) . 

We  have  already  derived  the  weakest-precondition  rule  for  the  sort2  instruction;  it  Is 

wp{  sort2(u  v)  P(u  v) ) ”>  {if  v < u then  P{v  u))  and 

{If  XI  i V then  P{u  v)) . 

Applying  this  rule  produces 

Goal  6i  achieve  {if  y < x then  x s z)  and 
{if  X iy  then  y i z) 

sort2{x  y) 
protect  X s y 
protect  perm{{x  y z)) . 

Intuitively,  the  first  task  of  this  goal, 

achieve  {if  y < x then  x i i)  and 
{if  X s y then  y s z) , 

IS  to  achieve  that  the  value  of  z Is  the  largest  of  the  three  values:  If  this  condition  holds  before 
sort2{x  y)  is  executed,  we  know  that  the  desired  condition  y s z will  be  true  afterwards.  This 
task  IS  still  another  simultaneous-goal  problem,  and  is  achieved  by  another  application  of  the 
simultaneous-goal  principle  We  will  not  describe  in  detail  how  this  task  is  accomplished.  The 
resulting  program  segment  is 

if  y < X then  sort2{x  z) 

if  X i y then  sort2{y  z) 
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The  corresponding  goal  Is 

Goal  9!  if  y < X then  sort2{x  z) 
if  X < y then  sort2(y  z) 
jort2(x  y) 
protect  X i y 
protect  permifx  y z)) . 

It  remains  to  check  the  protection  conditions.  Intuitively,  the  first  condition  x i y ii  satisfied 
because  It  occurs  immediately  after  the  sort2(x  y)  instruction,  which  achieves  this  relation.  The 
second  condition  perm{(x  y z))  holds  because  it  is  true  initially  and  it  is  preserved  by  the  three 
soft2  instructions  in  the  program.  In  practice,  these  conditions  would  be  established  by 
application  of  the  regression  and  weakest-precondition  rules.  (As  we  remarked,  our 
implementation  checks  these  conditions  repeatedly  while  the  program  is  being  modified  rather 
than  waiting  until  the  end  of  the  derivation.) 

The  final  program  we  obtain  is 

jorf3<x  y z)  <--  if  y < x then  sort2(x  z) 
if  X i y then  JOTt2(y  z) 
sortTfx  y)  . 

This  concludes  our  discussion  of  the  simultaneous-goal  rule;  we  will  see  further  applications 
of  this  rule  in  the  next  section,  in  the  synthesis  of  a somewhat  less  trivial  program. 


An  extended  discussion  of  the  simultaneous-goal  problem  appears  in 
Waldinger  [1977].  A similar  approach  to  the  problem  was  devised  by  Warren 
[1974]  but  he  did  not  use  the  weaKest-precondition  operator.  Other  methods 
have  been  applied  to  the  problem  by  Sacerdoti  [1975]  and  Tate  [1975] 


F.  Recursive  Programs 

The  structure-changing  programs  we  have  constructed  so  far  contain  no  recursive  calls. 
Our  next  example  Illustrates  how  the  recursion-formation  techniques  we  have  introduced 
earlier  can  be  applied  to  structure-changing  programs 

We  are  asked  to  construct  a program  to  find  the  maximum  max{a  n)  of  an  array  segment 

a[0  : n]  the  list  of  n+l  elements  o[0],  o(l] a[n].  The  specifications  for  this  program  may 

be  written  as 
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max{a  n)  <--  achieve  alt(a[0  : n])  « a:  and 
z f o[0  : n]  and 
only  I changed 

where  a is  an  array  of  numbers  and 

n IS  an  integer  and  / 

0 S r . 

Recaii  that  only  z changed  means  that  no  variable  other  than  z can  be  changed  by  the  program; 
In  particular,  this  condition  ensures  that  the  final  program  will  have  no  surprising  side  effects, 
and  that  it  will  not  satisfy  its  specifications  perversely,  say  by  setting  z and  all  the  elements  of 
the  array  segment  to  zero 

j Our  top-level  goal  is  thus 

I Goal  1:  achieve  all(a[0  : n])  < z and 

! r « a[0  : n]  and 

only  z changed  . 

' This  goal  has  the  form  of  a simultsneous-goal  problem.  The  third  condition,  only  t changed,  is 

of  course  true  initially,  so  we  decide  to  "achieve"  it  first;  it  will  then  be  eliminated  by  the 
achieve-  and  prove-ellmlnatlon  rules.  The  other  two  conditions  may  be  approached  In  either 
order.  We  obtain 

Goal  2:  achieve  alHa[0  ' n])  S z 
achieve  z c a[0  : n] 
protect  all{a[0  : n])  s z 
protect  only  z changed  . 

Assume  that  we  have  the  following  three  transformation  rules  that  relate  the  all  construct 
and  the  array  segment: 

• The  vacuous  rule 
P(,all{a[u  : hi]))  ->  true  if  u > w 

(any  condition  is  true  for  every  element  of  the  empty  segment), 

• The  singleton  rule 
P(all(a[u  : n/)))  ->  /’(a(u])  If  u - w 


(a  condition  is  true  of  every  element  of  a "singleton"  segment  If  the  condition  holds  for  that 
segment's  sole  element),  and 
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• The  dtcom position  rule 

P{all{a[u  : u)]))  •>  P(all{a[u  : tu-1]))  and  P(atw])  if  u < tu 

(a  condition  is  true  for  every  element  of  a segment  containing  two  or  more  elements  If  the 
condition  holds  for  the  final  element  of  the  segment  as  well  as  for  every  element  of  the  initial 
segment) 

We  focus  our  attention  on  the  first  task  in  Goal  2: 

Goal  3:  achieve  all(a[0  : n])  $ z . 

The  three  all  rules  each  match  this  goal.  The  vacuous  rule  requires  that  the  segment  be  empty; 
we  know  this  is  false  by  the  condition  0 s n in  the  Input  specification.  The  singleton  rule 
requires  that  the  segment  have  but  one  element,  i.e.,  that  0 - n;  we  cannot  prove  or  disprove 
this  condition,  so  we  make  it  the  basis  for  a case  analysis 

Case  0 x n (i.e.,  0 < n)  : Here,  the  singleton  rule  fails,  but  the  decomposition  rule,  which 
actually  requires  that  0 < n,  succeeds  in  decomposing  the  goal  into  the  conjunction  of  two 
conditions.  These  conditions  may  be  treated  separately  by  the  simultaneous-goal  principle, 
yielding 

Goal  4i  achieve  a/((a[0  : h-i])  s z 
achieve  a[n]  i z 
protect  alHalO  : n-l])  s z . 

We  will  consider  the  three  tasks  of  this  goal  in  turn  The  first  task,  to  achieve 
a//(a[0  : n-l])  s z , 

IS  an  instance  of  one  of  the  conditions  of  the  top-level  goal;  therefore,  the  recursion-formation 
rule  proposes  achieving  it  by  means  of  a recursive  call  max(a  n-l).  The  Input  and  termination 
conditions  for  this  call  are  straightforward 

We  now  focus  pur  attention  on  the  second  task  of  Coal  4, 

Goal  6i  achleva  a[n]  s z . 

Before  attempting  to  achieve  a condition,  the  achieve-elimination  rule  always  tries  to  determine 
whether  that  condition  is  already  true;  we  can  neither  prove  nor  disprove  it,  so  we  make  it  the 
basis  for  a further  case  analysis 

Casa  z < a[n] : In  this  case,  we  must  seek  alternate  means  to  achieve  Goal  5.  Recall  that  we 
have  a variable-assignment  formation  rule 
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achleva  P(u)  ->  prova  P(t) 

u t for  some  t 

where  u i$  a variable  and  t Is  an  expression.  Taking  P(u)  to  be  a[n]  i u,  f to  be  a[n],  and  u 
to  be  j:.  we  can  achieve  Goal  5 by  the  assignment  statement 

2 •-  a[n]  , 

because  a[n]  < a[n]. 

[Note  that  we  could  also  achieve  Goal  5 by  the  array-assignment  rule 
a[n]  ♦-  2 , 

or  the  sort2  instruction 
Jorf2(a[n]  2)  ; 

these  solutions  would  be  rejected,  however,  because  they  violate  the  protected  condition  only  z 
changfd] 

Casa  a[n]  s 2 : Here,  the  condition  of  Goal  b is  already  true,  and  can  be  "achieved*  by  the 
empty  program. 

We  have  achieved  Goal  5 in  both  cases;  the  conditional-formation  principle  yields  the 
program 


i/  2 < a[n]  then  2 ♦-  a[n]  . 

We  have  thus  completed  the  second  task  of  Goal  4. 

We  now  proceed  to  consider  the  third  task,  which  is  to  check  the  protection  condition 

Goal  6:  max{a  n-1) 
if  z < a[n] 
then  2 «-  oln] 
prove  af/(a(0  : n-l]  s 2 . 

Applying  the  prove-regression  rule 

5 ->  prova  wp{S  P) 

prove  P S , 

the  weakest-precondition  rule  for  the  if-then  construct 
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wp(  If  q thtn  5 P)‘>  if  q th*n  wp(S  P)  and 
If  not  q thtn  P , 

and  the  weakeit-precondition  rule  for  the  aiiignment  itatement 
wp(  u *-  t P(u) ) •>  P(t)  , 


we  obtain 

Goal  7i  max(a  n- 1) 

prove  if  i thtn  all{a[0  : n-U)  S o[n]  and 

if  a[n]  s t thtn  o//(o[0  ; n-l])  s z 
if  1 < ii[n] 
f/irn  7 «-  a[n)  . 

Note  that  max(a  n)  was  specified  to  achieve  the  condition 
a//(o[0  : n])  < 7 ; 

therefore,  by  mathematical  induction,  the  recursive  call  max(a  n-l)  can  be  assumed  to  achieve 
o//(o[0  : n-l])  S 7 


The  second  condition  we  are  asked  to  prove, 
if  a[n]  s 7 thtn  a//(a[0  ; n-l])  S z , 
follows  at  once  The  first  condition, 

if  t < a[n]  thtn  a//(a[0  : n-l])  S o(n]  , 
follows  directly  by  the  transitive  rule 

This  completes  the  final  task  of  Goal  4,  and  thus  we  have  achieved  the  condition  of  Goal  8, 
that  a//(a[0  : n])  s z,  for  the  case  where  0 < n.  The  remaining  case  is  more  easily  disposed  of. 

Case  n - 0 Here,  the  segment  a[0  : n]  has  only  one  element,  and  the  singleton  rule 
reduces  Goal  3 to  the  following 

Goal  Ai  achiava  a[0]  i z . 

This  condition  Is  achieved  by  the  assignment  statement 

7 ♦-  a[0]  , 


as  before. 
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We  have  constructed  program  segments  that  achieve  Goal  S in  each  case;  the  resulting 
conditional  segment  Is 

if  n • 0 
then  z *-  a[0] 
else  max(a  n-1) 
if  z < a[n] 
then  z *-  a[n]  . 

There  are  three  additional  tasks  in  Goal  2 that  we  must  perform:  We  must  achieve  the 
'■ondition 


z e a[0  : 7l]  , 


this  condition  is  already  true,  and  may  be  proved  by  application  of  the  regression  and  weakest- 
precondition  rules  Next,  we  must  check  that  the  protected  condition 

a//(a(0  :n))  s z 

IS  satisfied;  this  is  true,  because  we  have  just  constructed  a segment  that  achieves  this  condition, 
and  in  "achieving"  the  additional  condition  z t a[0  ; n]  we  made  no  changes  to  this  segment. 
Finally,  we  must  ensure  that  the  protected  condition 

only  z changed 

IS  satisfied;  this  Is  true,  because  only  assignments  to  z occur  in  the  program  we  have  constructed. 

Having  established  the  protection  conditions,  we  are  left  with  the  final  program 

maxia  n)  <-•  if  n • 0 

then  z ♦-  a[0] 
else  max(a  n-1) 
if  z < a[n) 
then  z «-  aln)  . 


O.  The  Modification  of  Recursive  Programs 

The  program-modification  technique  we  introduced  for  loop-free  programs  extends 
naturally  to  permit  the  modification  of  recursive  structure-changing  programs. 

Assume  we  are  given  the  program  max(o  n)  constructed  In  the  preceding  sectio.i;  this 
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program  finds  the  value  of  the  maximum  element  in  an  array.  Suppose  that  we  wish  to  extend 
that  program  to  obtain  a new  program  maxind*x(a  n)  for  finding  the  index  of  that  maximum 
element  as  well  as  Its  value.  In  other  words,  we  want  to  modify  the  program  max  to  achieve  the 
new  condition 

a[y]  - z and  0 s y s n 

while  protecting  the  original  condition 

a//(a[0  ; n])  S z and  z t a[0  : n] 

that  the  program  was  intended  to  achieve.  Note  that  we  do  not  protect  the  condition  only  t 
changed  that  the  program  originally  achieved;  this  is  because  we  want  to  change  the  value  of  y 
as  well  as  z Instead,  we  include 

only  y,  z changed 

among  the  new  conditions  to  be  achieved  by  maxindex. 

Our  modification  task  is  thus  specified  as  foUows. 

maxindexia  n)  <-•  i/  n • 0 

then  z ♦-  o[0] 
else  maxindexia  n-\) 
if  z < a(n] 
then  z *-  o[ti] 

achieve  a[y]  - z and  0 s y s n and  only  y,  z changed 
protect  a//(a[0  : n])  s z and  z c a[0  : n] 

where  a is  an  array  of  numbers  and 
n is  an  integer  and 
0 s n . 

Here,  we  have  replaced  the  recursive  calls  to  max,  the  old  program,  by  recursive  calls  to  the 
extended  program  maxindex  Goal  I is  fornoed  directly  from  these  specifications,  and  will  not 
be  copied  here 

Note  that  it  is  quite  necessary  to  protect  the  condition  aff<a[0  : n])  s z;  otherwise,  we  could 
achieve  the  new  conditions  by  perversely  resetting  z to  a[0]  and  setting  y to  0.  The  second 
condition,  on  the  other  hand,  is  actually  redundant;  if  a[y]  • z and  0 i y s n,  then  certainly 
z c a[0  : n]  Applying  the  usual  regression  and  weakest-precondition  rules,  we  derive 
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Goal  2;  ifn-0 

then  achieve  a[^]  - a[0]  and  0 iy  i n and  only  y,  z changed 
z *-  o[0] 

else  maxindexia  n-1) 
if  z < a[ni 

then  achieve  a[j]  - o[n]  and  0 iy  i n and  only  y,  z changed 
z *-  a[n] 

else  achieve  a[>]  • z and  0 i y s n and  only  y,  z changed 
protect  a//(a[0  : n])  £ z and  z c a[0  : n]  . 


The  task 

achieve  a[y]  - a[0]  and  0 iy  i n and  only  y,  z changed  , 
which  occurs  in  the  branch  for  which  n - 0,  is  found  to  be  achieved  by  the  assignment 
y *-  0 , 

by  application  of  the  simultaneous-goal  principle  and  the  variable-assignment  formation  rule. 
Similarly,  the  task 

achieve  a[y]  - a(n]  and  0 i y S n and  only  y,  z changed  , 

which  occurs  after  the  recursive  call  in  the  case  z < a[n],  is  found  to  be  achieved  by  the 
assignment 

y-n. 

Finally,  the  task 

achieve  aly]  - z and  0 i y i n and  only  y,  z changed  , 

occurs  immediately  after  the  recursive  call  maxin<<rjc(o  n-l)  in  the  case  a[n]  i z.  The  recursive 
call  can  be  assumed  inductively  to  achieve  the  condition 

a(y]  - z and  0 s y s n-l  and  only  y,  z changed  ; 

thus,  the  desired  condition  is  already  true. 

The  protected  condition 

a//(<i[0  : n])  s z and  z < a[0  : n]  , 

which  was  achieved  by  our  original  program  max(a  n),  has  not  been  affected  by  any  of  our 
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modifications;  the  only  instructions  we  have  added  are  assignments  to  j|.  The  final  maxindex 
program  we  obtain  is  thus 

maxind*x(a  n)  </  n ■ 0 
thin  y *■  0 
z «-  a[0] 

0lst  maxlndtx{a  n-l) 

If  X < o[ni 
then  y *-  n 

. z *-  a[n]  . 

The  modification  of  recursive  programs  can  be  initiated  by  the  simultaneous-goal  principle 
if  the  program  constructed  to  achieve  one  of  the  goal  conditions  happens  to  be  recursive. 
However,  modification  of  a given  program  may  also  be  regarded  u an  independent 
programming  task;  this  application  is  discussed  further  in  Section  5C. 
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6.  IMPLICATIONS  FOR  PROGRAMMING  METHODOLOGY 

In  program  synthesis  as  we  have  defined  it,  a person  formulates  the  purpose  of  the  program 
he  wants  without  indicating  a procedure  to  achieve  that  purpose.  In  practice,  even  the  most 
computationally  naive  user  of  a program-synthesis  system  is  likely  to  have  some  idea  of  an 
algorithm  that  could  be  employed  by  the  desired  program.  This  algorithm  may  not  be  entirely 
satisfactory  it  may  not  achieve  all  the  desired  conditions,  it  may  be  incompletely  specified,  or  it 
may  lead  to  an  inefficient  program  Nevertheless,  it  would  be  foolish  to  prevent  the  user  from 
conveying  this  information  to  the  system,  because  it  is  easier  to  derive  a program  from  a 
partially  specified  algorithm  than  from  a specification  that  expresses  only  the  program's 
purpose  In  this  section,  we  will  show  how  the  program-synthesis  techniques  we  have  already 
introduced  can  be  applied  to  transform  a partially  specified  procedure  into  a complete  program. 

Actually,  we  have  already  seen  some  examples  in  which  the  specifications  had  a procedural 
component  In  the  maxindex  example  (Section  ^G),  our  specifications  were  given  in  the  form  of 
a complete  max  program  with  some  additional  conditions  to  be  achieved.  In  the  reverse 
example  (Section  3C),  the  specifications  were  composed  of  a complete  reverse  program,  which 
was  transformed  into  a more  efficient  equivalent  These  examples  were  introduced  to  illustrate 
particular  program-synthesis  techniques.  The  emphasis  in  this  section  will  be  on  the  actual 
task  performed 

We  will  consider  separately  three  ways  in  which  the  procedural  components  of  a 
specification  can  be  presented. 

• Program  transformation.  The  specifications  are  given  in  the  form  of  a clear— perhaps 

inefficient— program,  which  is  then  transformed  into  an  efficient— perhaps  unclear- 
equivalent. 

• Data  abstraction.  The  specifications  are  given  in  the  form  of  a complete  program  that 

operates  on  certain  abstract  data  types,  structures  (such  as  sets,  stacks,  or  graphs)  whose 
properties  are  expressed  precisely  but  whose  machine  representation  is  unspecified;  the 
program  is  then  transformed  to  replace  each  operation  on  the  abstract  data  types  by  a 
corresponding  concrete  operation  on  a chosen  machine  representation. 

• Program  modification.  We  are  given  a complete  program  that  performs  one  task  successfully; 

we  wish  to  extend  the  program  to  achieve  an  additional  condition,  while  still  performing 
Its  original  task. 

Although  we  consider  each  of  these  topics  separately,  the  same  techniques  can  be  applied  to 
transform  a procedure  whose  description  is  subject  to  all  three  modes  of  imprecision.  In  other 
words,  the  given  specifications  could  present  an  inefficient  procedure,  expressed  In  terms  of 
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abstract  structures,  that  needs  to  be  extended  to  achieve  additional  conditions.  Of  course,  there 
are  other  ways  in  which  the  description  may  be  imprecise  besides  the  three  we  will  discuss  here. 


A.  Transformation:  Programs  ->  Better  Programs 

Often  the  clearest,  simplest  program  for  a given  task  may  not  be  the  most  efficient;  if  we 
attempt  to  construct  an  efficient  program  for  the  task  at  once,  our  result  is  likely  to  be  unclear, 
and  perhaps  incorrect  as  well.  It  has  been  suggested,  therefore,  that  we  construct  our  program 
in  two  stages:  we  begin  by  setting  efficiency  considerations  aside  for  awhile,  we  construct  as 
clear  and  straightforward  a program  as  possible.  We  then  transform  this  program  to  make  it 
more  efficient,  possibly  losing  some  clarity  during  the  process. 

It  IS  argued  that  the  programs  produced  in  this  way  are  more  likely  to  be  correct  than 
programs  produced  by  the  conventional  one-phase  method.  The  first  version  is  likely  to  be 
correct  by  virtue  of  its  clarity;  the  second  version  is  produced  by  the  application  of 
transformation  rules  that  preserve  the  correctness  of  the  first  version  while  improving  iu 
efficiency. 

We  have  already  seen  program-synthesis  techniques  applied  to  a transformation  problem,  in 
Section  3C  In  that  example,  we  were  given  the  following  program  for  reversing  a list; 

revtrstil)  mpty{t) 
lAfn  nil 

tlst  append{rev€rse(lail(l)) 
list{head{D) ) . 

appendUf  /j)  <-«  if  tmpty(t^) 
then  /j 

else  consiheadU f) 

append(tall{lf)  1 2)) 

Treating  this  program  itself  as  the  specifications,  we  developed  the  following  system  of  two 
programs  for  performing  the  same  task: 

reversed)  <•■  if  emplyd) 
then  nil 

else  reversegend  nil)  , 


where 
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rtvtTitgtnd  m)  <--  if  empty(taU(i)) 

then  cons(htadd)  m) 
ehe  reversegen(jail(l) 

cons(head{l)  m)) . 

The  original  reverse  program  is  quite  inefficient;  each  execution  may  require  many  calls  to  the 
append  program;  each  of  these  calls  to  append  produces  a new  copy  of  its  first  argument.  On 
the  other  hand,  in  the  final  system  of  programs,  the  expensive  append  operation  Is  replaced  by 
the  economical  cons.  Furthermore,  the  recursion  is  of  a special  form  that  can  be  evaluated 
without  the  use  of  a stack,  in  fact,  this  system  can  be  converted  to  the  following  Iterative  reverse 
program  by  application  of  a recursion-removal  transformation  rule 

reversed)  <--  if  emplyd) 

then  output(nU) 
else  m •-  nil 

while  not  empty(taild)) 
do  m *-  consiheadd)  n) 

I «-  taild) 

output{cons[headd)  m))  . 

By  exploiting  the  properties  of  the  operations  in  the  original  reverse  program,  we  have 
managed  to  transform  it  to  a more  efficient  program  that  achieves  the  same  purpose  by  a 
fundamentally  different  method. 

In  this  example,  our  specifications  were  given  in  the  form  of  a complete  program,  with  no 
other  indication  of  the  purpose  to  be  achieved.  We  were  fortunate  to  perform  the  same  task  by 
an  entirely  different  and  more  efficient  method.  In  general.  If  the  specification  of  the  program 
Is  purely  procedural,  such  radical  Improvements  are  difficult  to  achieve;  In  omitting  any 
statement  of  purpose  from  the  given  specification,  we  are  biased  toward  adopting  the  algorithm 
of  the  given  program.  Instead  of  seeking  to  achieve  the  same  purpose  In  a new  way. 

For  example,  suppose  that  we  want  to  construct  a program  to  sort  a list  of  numbers.  Our 
description  of  the  desired  program  might  be 

sortd)  if  ernptyd) 
then  nil 

else  mergeiheadd)  sortd<*dd)))  , 

where 

mergeix  1)  <-•  if  ernptyd) 
then  iisl(x) 
else  If  X i headd) 
then  cons(x  1) 
else  consiheadd) 

mergeix  taild)))  ■ 
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The  sorting  method  employed  by  this  program  is  intrinsically  inefficient.  The  program 
contains  no  explicit  statement  that  the  list  it  produces  is  intended  to  be  ordered.  Without  such 
a statement,  it  is  difficult  to  imagine  a system  stumbling  across  a more  efficient  sorting  method. 

A more  practicable  approach  would  be  to  have  the  user  specify  the  purpose  of  the  given 
program  along  with  the  program  itself.  The  system  would  then  apply  correctness-prtserving 
transformations,  which  could  alter  the  given  program  to  achieve  the  tame  purpose  in  a 
fundamentally  different  way. 


The  pure  program-transformation  approach  has  been  advocated  by 
Burstall  and  Darlington  [1977],  Knuth  [1974],  Standish  et  al.  [1976],  and 
others.  Gerhart  [1975]  introduces  a system  of  correctness-preserving 
transformations.  An  experimental  system  to  improve  programs  by  successive 
transformation  was  implemented  by  Darlington  and  Burstall  [1976]. 


B.  Abstract  Data  Structures 

Out  of  the  different  diagnoses  of  the  causes  of  our  programming  ills,  there  arise  different 
therapies  One  schcxil  of  thought  attributes  much  of  the  difficulty  of  programming  to  the 
prcKess  of  encoding  high-level  data  structures  in  terms  of  the  constructs  available  in  the  target 
programming  language. 

According  to  this  school,  we  design  an  algorithm  in  our  minds  in  terms  of  abstract  data 
structures,  structures  such  as  sets,  queues,  or  graphs  whose  properties  are  specified  but  whose 
precise  implementation  is  undetermined.  In  these  terms,  the  "mental  algorithm"  is 
straightforward  and  easy  to  formulate. 

The  difficulty  arises  when  we  attempt  to  express  our  mental  algorithm  in  terms  of  the 
primitive  constructs  of  the  target  language,  such  as  arrays  or  lists.  Because  the  machine 
representations  at  our  disposal  do  not  correspond  precisely  to  the  abstract  data  structures  of  our 
mental  algorithm,  an  act  of  paraphrase  is  involved  in  the  programming  process.  We  must 
simultaneously  formulate  our  algorithm  and  express  it  in  terms  of  machine  operations. 
Furthermore,  there  are  often  many  possible  implementations  for  the  same  abstract  data 
structure,  only  after  we  have  completely  described  our  algorithm  in  abstract  terms,  and  can  see 
what  operations  are  to  be  performed  on  the  structure,  can  we  decide  which  implementation  will 
lead  to  the  most  efficient  program. 

It  has  therefore  been  proposed  that  we  construct  our  program  in  two  stages;  we  begin  by 
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constructing  a clear  program  m terms  of  the  abstract  data  structures  of  our  mental  algorithm; 
only  then  do  we  choose  a representation  for  the  abstract  data  structures,  and  transform  our 
program  accordingly  For  instance,  we  would  first  express  our  algorithm  in  terms  of  high-level 
operations  such  as  popping  an  element  from  a queue  or  adding  an  element  to  a set;  then  we 
would  decide  how  to  represent  the  queue  or  set.  as  an  array  or  list.  say.  Facilities  might  be 
provided  to  perform  the  required  transformations  automatically,  or  at  least  to  ensure  that  they 
are  done  correctly 

The  transformation  process  may  be  regarded  as  a program-synthesis  task.  The  specification 
for  this  task  is  the  program  expressed  in  terms  of  the  abstract  data  structures;  the  operations  on 
these  structures  are  considered  to  be  nonprimitive  constructs.  The  properties  of  the  abstract 
data  structures  and  their  operations  are  stated  as  transformation  rules.  The  final  program  will 
be  equivalent  to  the  original,  but  all  the  nonprimitive  abstract  operations  will  have  been 
reformulated  in  terms  of  primitive  target-language  constructs. 

For  example,  suppose  we  are  writing  a program  that  deals  with  queues  as  an  abstract  data 
structure  We  may  have  three  operations  on  a queue:  a push  operation,  which  inserts  an 
element  at  the  end  of  the  queue,  a lop  operation,  which  produces  the  first  element  of  the  queue; 
and  a pop  operation,  which  removes  the  first  element  from  the  queue.  Informally,  we  can 
represent  the  properties  of  these  operations  by  the  rules 

push(y  queue(x^  x„))  ->  queue{x^  ...  x„  y) 

topiqueueiy  X|  . . . x„))  ->  y if  queue(y  x,  . . . x„)  is  nonempty 

popiqutuiiy  X|  . . . x„))  ■>  queutix^  ...  x„)  if  queutiy  x^  ...  x„)  is  nonempty. 

Now,  suppose  that  we  have  written  our  program  in  terms  of  abstract  queues,  but  that  our 
target  programming  language  requires  us  to  represent  our  queues  in  terms  of  lists.  The  obvious 
representation  is  to  encode  the  queue  directly  as  a list,  i e., 

encode  i(queue(x,  x„))  ->  /ijf(X|  . . . x„)  . 

An  alternate  representation  is  to  encode  the  queue  u a list  with  the  elements  reversed,  ie., 
encode2(queue(x , ...  x„))  ->  /is/(x„  ...  x,)  . 

Assume  that  we  have  thosen  the  first  encoding. 

To  our  encoding  operation  encodel  there  corresponds  the  opposite  decoding  operation 
decode  Ulistixf  ...  x^))  ->  queue(x-  ...  x„)  . 


Implications  for  Programming  Methodology 


77 


Our  synthesis  task  is  now  to  construct  concrete  operations  on  lists  that  correspond  under  our 
chosen  encoding  to  the  abstract  push,  top,  and  pop  operations,  i.e., 

push\(y  1)  <--  encode \{push{y  decode\{l))) 

lop\{l)  top{decode\U)) 
where  decode \(l)  is  nonempty 

pop\(l)  <••  encode\{pop(decode\U))) 
where  decode\{l)  is  nonempty, 

where  I is  a list.  We  can  consider  these  descriptions  as  specifications  for  a synthesis  task  in 
which  push,  top,  pop,  encode],  and  decode]  are  all  regarded  as  nonprimitive  constructs.  By 
including  the  rules  describing  the  properties  of  these  constructs  among  our  transformation  rules, 
and  applying  our  usual  program-synthesis  techniques,  we  obtain  the  following  concrete 
implementations: 

push  l()i  1)  <--  if  empty  (/) 
then  listiy) 
else  cons{head{l) 

pushiy  tailU)))  , 


top  HD  <--  headd)  , 


and 


popHD  <--  tail(l)  . 

The  final  program  is  then  obtained  by  replacing  the  abstract  operations  push,  top,  and  pop 
by  the  concrete  implementations  push],  top],  and  pop]  In  the  given  program. 

In  this  implementation,  top]  and  pop]  may  be  executed  directly,  but  push]  involves 
searching  down  the  entire  queue.  Therefore,  we  might  choose  this  Implementation  if  the  top 
and  pop  operations  must  be  performed  quickly,  but  the  push  operation  Is  permitted  to  take 
more  time 

If  the  reverse  situation  is  the  case,  and  push  is  the  more  critical  operation,  we  may  choose 
the  alternate  representation,  In  which  the  elements  of  the  queue  appear  on  the  list  in  reverse 
order,  i e., 


encode2(queue{x f . . . x^))  ->  /ijt(x„  ...  X|) 


The  corresponding  implementations  that  result  are 
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push2{y  1)  <--cons(y  t)  , 

top2(l)  <--  if  empty(tail{l)) 
then  head(l) 
else  top2Uail{l))  , 

and 

pop2(l)  <--  if  emptyltaiHD) 
then  nit 

else  cons{hea<i{l) 

pop2(tail{l)))  . 

In  this  representation,  the  push  operation  becomes  quite  economical,  but  the  top  and  pop 
operations  become  correspondingly  more  expensive. 

The  problems  that  arise  in  translating  abstract  data  structures  into  concrete  representations 
require  all  the  synthesis  techniques  we  have  considered.  However,  these  problems  are  of  a 
more  limited  scope  and  require  less  invention  than  the  more  general  synthesis  problem.  It  is 
likely  that  program-synthesis  techniques  will  become  practical  for  such  relatively  restricted 
problems  long  before  the  general  problem  is  solved. 


The  data-abstraction  methodology  has  been  investigated  extensively  (see, 
(or  example,  Liskov  and  Zilles  [1975]  and  Guttag,  Horowitz,  and  Musser 
[1976]).  Systems  in  which  the  representations  for  certain  abstract  data 
structures  are  selected  automatically  have  been  implemented  by  Low  [1976] 
and  Schwartz  [1974],  Our  queue  example  follows  Hewitt  and  Smith  [1975],  at 
a safe  distance. 


C.  Progrram  Modification 

It  IS  often  remarked  that  programmers  spend  more  of  their  time  in  modifying  old  programs 
to  achieve  additional  purposes  than  in  constructing  new  programs  These  modification  tasks 
are  conceptually  far  less  challenging  than  the  original  programming  effoft.  However,  a 
programmer  is  especially  prone  to  err  in  modifying  a program-.  For  one  thing,  if  the  original 
program  is  complex,  it  may  be  difficult  to  find  all  the  points  at  which  changes  must  be  made. 
Furthermore,  the  programmer  may  not  know  or  remember  how  the  program  works;  he  may 
interfere  with  its  original  functioning  in  introducing  the  required  changes. 
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Thus,  the  difficulty  of  program  modification  may  be  attributed  to  its  complexity  as  a 
bookkeeping  chore  rather  than  to  its  challenge  as  a creative  endeavor.  For  this  reason, 
program  modification  is  another  area  in  which  program-synthesis  techniques  are  likely  to  find 
their  earliest  application 

We  have  already  introduced  a program-modification  technique,  using  protected  conditions, 
as  a basis  for  our  simultaneous-goal  principle  in  program  synthesis.  This  technique  can  also  be 
applied  directly  to  the  program-modification  task.  Thus,  we  modify  the  given  program  to 
achieve  a new  condition,  while  protecting  the  condition  the  program  was  originally  intended  to 
achieve. 

We  have  seen  one  example  (in  Section  4C)  in  which  our  program-modification  technique 
was  applied  to  extend  a program  for  finding  the  value  of  the  maximum  element  of  an  array,  to 
also  find  the  index  of  that  element.  The  original  program. 

max{a  n)  <--  i/  n - 0 

then  z *-  a[0] 
else  max{a  n-1) 
if  z < <i[n] 
then  z <-  o[n]  , 

was  constructed  to  achieve  the  condition 

alHa[0  : n])  < z and  z e o[0  ; n]  and  only  z changed. 

This  program  wai  then  modified  to  achieve  the  additional  condition 

z - a{y]  and  0 s y s n and  only  y,  z changed 

while  still  maintaining  two  of  the  original  conditions, 

o//(a[0  : n,)  and  z * <i(0  : n]  . 

This  modification  task  was  specified  as 

maxindexia  n)  <--  i/  n - 0 

then  z «-  a[0] 
else  maxindexia  n-1) 
if  z < a(ni 
then  z «-  a[n] 

achieve  aly]  - z and  0 i y s n and  only  y,  z changed 
protect  all(a[0  : n])  s z and  z « atO  : n]  . 

The  achieve  task  ensures  that  the  modified  program  will  fulfill  its  new  purpose,  and  the 
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protect  task  guarantees  that  in  modifying  the  program  we  will  not  interfere  with  its  original 
functioning. 

From  the  above  specification,  we  obtained  the  modified  program 

maxindex(a  n)  <-»  i/  n - 0 

then  y 0 
z «-  a[0] 

else  maxindex{a  n-1) 
if  z < a[n] 
then  y *-  n 
z «-  o[n]  . 
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e.  LOOSE  ENDS 

A.  A Footnote  on  Structured  Programming 

In  program  synthesis  we  attempt  to  reproduce  by  machine  the  same  process  that  is  carried 
out  by  the  "structured  programmer"  by  hand.  However,  the  basic  programming  principles  we 
employ  in  this  paper  are  not  merely  machine  implementations  of  the  principles  of  structured 
programming.  Let  us  briefly  examine  the  derivation  of  a program  in  the  style  of  a structured- 
programming  practitioner,  to  illustrate  some  of  the  essential  differences. 

The  program  €xp{x  y)  we  construct  is  intended  to  set  the  value  of  the  variable  z to  be  the 

exponential  of  two  integers  x and  y , where  x is  positive  and  y it  nonnegative.  We  assume 
we  are  given  a number  of  properties  of  the  exponential  function,  including 

u*'  - 1 if  u I*  0 and  v - 0 , 

if  i;  is  even,  and 

« U" (u-  if  V is  odd  , 

where  u,  v,  and  tv  are  any  integers.  Here,  + denotes  integer  division.  Written  In  our  notation, 
the  top-level  goal  of  a structured-programming  derivation  is 

Goal  A:  achieve  z • xy 

(where  the  exponential  function  is  considered  to  be  nonprimitive).  This  goal  can  be 
decomposed  into  the  conjunction  of  two  conditions 

Goal  B:  achieve  z-xxyy  - and  Jty  - 0 , 

The  motivation  given  for  this  step  is  that,  initially,  we  can  achieve  the  first  condition 
z-xxyy  - xy  easily  enough  (by  setting  xx  to  x,  yy  to  y,  and  z to  1);  if  we  manage  to  achieve  the 
second  condition  yy  - 0 subsequently,  while  maintaining  the  first  condition,  we  will  have 
achieved  our  goal 

For  this  purpose,  we  establish  an  iterative  loop,  whose  invariant  is  z-xxyy  - x?  and  whose 
exit  condition  is  yy  - 0;  the  body  of  the  loop  must  bring  yy  closer  to  zero  while  maintaining  the 
invariant 

By  exploiting  the  known  properties  of  the  exponential  and  other  arithmetic  functions,  we 
are  led  ultimately  to  a final  program,  e g., 
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txp{x  y)  <—  {xx  yy  i)  *■  {x  y \) 
while  yy  <•  0 
do  if  eveniyy) 

then  (xx  yy)  *-  (xx.  xx  yy+2) 
else  (xx  yy  e)  *■  (xx- xx  yy+2  xx- z) . 

The  weak  point  of  this  derivation  seems  to  be  the  passage  from  Goal  A to  Coal  B.  This 
step  IS  necessary  to  provide  the  invariant  for  the  loop  of  the  ultimate  program.  However,  how 
do  we  know  to  use  this  invariant  unless  we  already  know  the  final  program  in  advance?  Why 
should  we  generate  this  goal  instead  of  one  of  the  following,  equally  plausible  alternatives; 

Goal  B| : achieve  z + xxfi  > x)  and  xx  • 0 

(to  be  initialized  by  (xx  yy  z)  +-  (x  y 0)], 

Goal  Bji  achieve  - xy  and  yy  - I 

[to  be  initialized  by  (yy  z)  *-  (y  x)],  or  even 

Goal  B3:  achieve  (z-xx)yy  - x?  and  xx  - yy  - I 

[to  be  initialized  by  (xxyy  z)  *-  (xy  I)  or  by  (xx  yy  z)  ♦-  (I  y x)]  ? 

Each  of  these  steps  can  be  motivated  by  the  same  considerations  that  justified  the  generation  of 
Coal  B,  but  none  of  them  leads  to  an  exponential  program  so  readily. 

Our  instructors  at  the  Structured  Programming  School  have  urged  us  to  find  the 
appropriate  invariant  assertion  before  introducing  a loop  But  how  are  we  to  select  the 
successful  invariant  when  there  are  so  many  promising  candidates  around? 

The  corresponding  derivation  of  the  same  program  by  the  program-synthesis  techniques  of 
this  paper  requires  no  such  precognitive  Insights.  By  using  the  same  properties  of  the 
arithmetic  functions  that  were  exploited  In  the  structured-programming  derivation,  we  can 
reduce 


Goal  A:  compute  xf 

to  the  two  subgoals 

Goal  B:  compute  (x- x)?*^ 


(in  the  case  that  y is  even)  and 
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Goal  C:  compute  x*  (*•  *))*‘*'^ 

(in  the  case  that  ■y  is  odd).  Only  after  we  observe  that  the  subexpression  {x-x)y*^  , which 

occurs  in  both  subgoals,  is  an  instance  of  the  expression  x?  in  the  top-level  goal,  do  we  actually 
decide  to  introduce  a recursive  call  exp{x>x  y*2)  to  compute  these  subexpressions.  The 
resulting  program  is 

exp(x  y)  <--  if  y - 0 
then  X 

else  if  eveniy) 

thenexp(x-x  y+2) 
else  x-exp(x-x  y+2)  ■ 

This  IS  a recursive  version  of  the  previous  iterative  exponential  program,  and  can  actually  be 
transformed  into  that  program  by  standard  recursion-removal  techniques. 

The  recursive  calls  in  the  above  program  arose  naturally  from  the  tree  of  goals  in  the 
derivation,  and  the  structure  of  the  final  program  reflects  the  structure  of  that  tree.  In  contrast, 
the  derivation  tree  for  the  iterative  program  had  to  be  forcibly  manipulated  to  induce  the 
invariant  to  appear 

Recursion  seems  to  be  the  ideal  vehicle  for  systematic  program  construction;  its  use  accounts 
for  the  relative  simplicity  of  the  above  derivation.  In  choosing  to  emphasize  Iteration  instead, 
the  proponents  of  structured  programming  have  had  to  resort  to  more  dubious  means. 


The  principles  of  structured  programming  have  been  described  often  in  the 
literature,  e.g.,  by  Dahl,  Diikstra,  and  Hoare  [1972],  Wirth  [1974],  and  Dijkstra 
[19761 


B.  Implementation 

It  IS  difficult  to  develop  or  evaluate  heuristic  techniques  without  experimenting  with  an 
implementation  The  DEDALUS  (DEDuctive  ALgorlthm  Ur-Synthesizer)  system  is  a 
laboratoiy  tool  rather  than  a practical  product.  The  system  is  implemented  In  QLISP  (Wilber 
[1976]),  an  extension  of  INTERLISP  (Teitelman  [197t])  that  Includes  pattern-matching  and 
backtracking  facilities.  In  this  section,  we  will  describe  some  of  the  special  characteristics  of  our 
implementation  without  going  into  very  much  detail. 
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The  specifications  are  expressed  in  a LISP-like  notation.  Thus,  the  output  specification  for 
the  Itssall  program,  which  we  wrote  as 

X < all{t)  , 

IS  represented  in  the  DEDALUS  system  as 
(LESS  X (ALL  D). 

The  output  specification  for  the  ged  program,  which  we  wrote  as 
maxjz  : z|x  and  zty)  , 

IS  represented  as 

(MAX  (SETOF  Z (AND  (DIVIDES  Z X) 

(DIVIDES  Z Y)))). 

The  target  program  is  also  expressed  in  LISP  syntax. 

The  transformation  rules  are  expressed  as  programs  in  the  Qj-ISP  programming  language. 
For  example,  the  rule  that  we  denoted  by 

P and  true  ->  P 

IS  represented  by  the  QLISP  program 

((^LAMBDA  (AND  *-P  TRUE)  IP). 

The  rule  we  wrote  as 

u{v  ->  true  ~ if  u is  an  integer  and  v • 0 
IS  expressed  as 

(QJ_AMBDA  (DIVIDE  ♦-U  vV) 

/ (INSIST  (PROVE  ('(INTEGER  lU)))) 

/ (INSIST  (PROVE  ('(EQUAL  IV  0)))) 

TRUE). 

Although  the  reader  who  is  unfamiliar  with  the  QLISP  language  may  not  understand  all  the 
details  of  the  above  programs,  he  may  still  observe  that  they  are  similar  in  form  to  the  rules 
that  they  represent;  the  features  of  the  QLISP  language  make  this  representation  fairly  direct. 
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Because  rules  are  represented  as  programs,  we  are  allowed  the  full  power  of  the  programming 
language  in  expressing  each  rule. 

The  DEDALUS  system  currently  contains  more  than  a hundred  such  transformation  rules. 
In  expanding  the  system  to  handle  a new  subject  domain,  we  simply  introduce  new  rules. 

The  rules  of  the  system  are  classified  according  to  their  pattern,  their  left-hand  side.  This 
pattern  describes  the  class  of  subgoals  to  which  the  rule  can  be  applied.  Thus,  the  rules 

u\v  •>  true  if  . . . 

and 

u|t;  ->  u|ii-u  if  . . . 

both  have  pattern  u|v,  and  can  be  applied  to  goals  such  as 
comput*  X I y^-t  . 

When  a new  goal  is  generated,  the  system  retrieves  those  rules  whose  patterns  match  the  form 
of  the  goal.  This  retrieval  is  facilitated  by  arranging  the  rules  in  a classification  tree  according 
to  their  patterns;  thus  the  two  rules  above  would  be  classified  on  the  same  branch  of  the  tree. 
This  mechanism  allows  us  to  avoid  matching  every  rule  in  the  system  against  each  newly- 
generated  goal 

If  no  rule  matches  the  entire  expression  of  a goal,  iu  subexpressions  are  established  as 
subgoals.  If  no  rule  matches  any  subexpression  of  a given  goal,  a failure  occurs,  and 
backtracking  is  invoked;  the  system  attempts  to  find  an  alternate  transformation  that  applies  to 
a previous  subgoal. 

The  QLISP  pattern-matcher  has  special  provisions  for  matching  commutative  functions. 
Thus,  because  the  and  operation  Is  commutative,  the  rule 

P and  true  ->  P , 

represented  as  the  QLISP  program 

(QLAMBDA  (AND  -P  TRUE)  IP), 

can  be  applied  to  goals  of  form  "true  and  P"  as  well  as  "P  and  true".  For  this  reason, 
commutativity  rules  such  as 

P and  Q->  Qond  P 
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arc  not  necessary  in  the  DEDALUS  system. 

This  kind  of  matching  also  occurs  in  the  recursion-formation  rule,  in  determining  whether  a 
new  goal  is  an  instance  of  some  earlier  goal.  For  example,  in  the  actual  synthesis  of  the  gcd 
program,  the  top-level  goal 

compute  max{z  : z|x  and  z|y) 

was  regarded  as  an  instance  of  itself  with  the  roles  of  x and  y reversed,  because  the  and 
function  is  commutative.  The  recursion-formation  rule,  therefore,  was  able  to  propose  the 
recursive  call  gcd(y  x). 

Currently,  the  DEDALUS  implementation  incorporates  the  principles  of  conditional 
formation,  recursion  formation  (including  the  termination  proofs),  and  procedure  formation,  but 
not  generalization  or  the  formation  of  structure-changing  programs.  The  techniques  for 
deriving  straight-line  structure-changing  programs  were  implemented  in  a separate  system  (see 
Waldinger  [1977]). 

Representative  samples  of  the  programs  constructed  by  the  current  DEDALUS  system  are 
the  following. 

Numerical  Programs: 

• the  subtractive  gcd  algorithm 

• the  Euclidean  gcd  algorithm 

• the  binary  gcd  algorithm 

• the  remainder  of  dividing  two  integers 

List  Programs: 

• finding  the  maximum  elenrent  of  a list 

• testing  if  a list  is  sorted 

• testing  if  a number  is  less  than  every  element  of  a list  of  numbers  {lessall) 

• testing  if  every  element  of  one  list  of  numbers  is  less  than  every  eWment 
of  another  (allall) 

Set  Programs: 

• computing  the  union  or  intersection  of  two  sets 

• testing  if  an  element  belongs  to  a set 

• testing  If  one  set  is  a subset  of  another 

• computing  the  Cartesian  product  of  two  sets  (cart) . 


Loose  Ends 


87 


C.  Historical  Remarks 

In  this  section  we  trace  briefly  the  history  of  the  deductive  approach  to  program  synthesis. 

The  early  heuristic  compiler  of  Simon  [1963]  constructed  simple  straight-line  list-processing 
programs  from  descriptions  of  the  expected  input  and  desired  output;  the  system  was  based  on 
the  Gcneral-Problem-Solver  approach. 

A later  group  of  systems  was  based  on  the  resolution  theorem- proving  approach,  the 
specifications  for  the  desired  program  were  translated  into  an  equivalent  theorem-proving 
problem,  and  the  desired  program  was  derived  from  the  corresponding  proof.  (See,  eg.,  Green 
[1969],  Waldinger  and  Lee  [1969],  and  Lee,  Chang,  and  Waldinger  [1974].)  These  systems 
could  produce  conditional  programs,  but  their  loop-formation  ability  was  rudimentary;  the 
required  mathematical-induction  proofs  were  awkward  to  perform  in  the  resolution  formalism. 
Efforts  to  improve  the  synthesis  of  loops  within  a (non resolution)  theorem-proving  approach 
are  described  in  Manna  and  Waldinger  [1971]. 

A program-synthesis  system  based  on  the  program-verification  formalism  of  Hoare  [1969]  is 
described  by  Buchanan  and  Luckham  [1974].  Their  system  was  Implemented  using  some  of  the 
facilities  of  PLANNER  (Hewitt  [1971]);  it  required  that  the  loops  be  specified  in  advance  by 
the  user. 

The  more  recent  work  in  program  synthesis  is  too  extensive  and  too  varied  to  be 
summarized  here.  Papers  related  to  aspects  of  the  deductive  approach  are  mentioned  in  the 
appropriate  sections  of  the  text;  some  of  the  other  approaches  are  discussed  in  the  next  section. 


D.  Other  Approaohes 

The  program-synthesis  approach  we  have  followed  requires  that  we  provide  complete 
spe'‘ificatioris  for  the  desired  program  expressed  in  an  artificial  language.  It  has  been  argued 
that  these  specifications  are  difficult  to  provide,  and  many  alternate  approaches  have  been  built 
around  different  specification  Khemes. 

• Sample  input-output  pairs.  In  this  approach  (eg.,  see  Hardy  [1975],  Summers  [1977]),  the 
program  is  described  by  giving  typical  inputs  and  the  corresponding  outputs.  Thus, 

(A  B C)  ->  (C  B A) , (A  (B  C)  D)  ->  (D  (B  C)  A) 

suggests  a program  to  reverse  a list.  Such  specifications  are  natural  and  easy  to  formulate. 
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However,  in  constructing  the  pairs  one  must  be  careful  to  avoid  ambiguities;  for  instance  the 
pairs 

(6  -1)  ->  2 . (13  V)  ->  6 . (23  13)  ->  10 

could  represent  either  the  subtraction  or  the  remainder  program.  Furthermore,  the  approach 
demands  that  the  system  be  able  to  generalize  from  examples,  not  always  an  easy  task;  for 
instance,  it  is  not  immediately  obvious  that 

(2  2)->4,  (3  6) ->6,  (7  1) ->7,  (14  21) ->  42 

denotes  a least-common-multiple  program.  Moreover,  the  generalization  task  is  redundant:  the 
system  is  trying  to  guess  a relation  that  the  user  knows  perfectly  well,  but  is  unable  to  express 
directly  in  this  notation. 

• Sample  execution  traces  In  this  approach,  the  user  provides  a detailed  trace  of  the 
performance  of  the  desired  program  on  some  typical  inputs.  (See,  eg.,  Biermann  and 
Krishnaswamy  [1976].)  Thus,  the  trace 

(12  18) -.(6  12) -4  (0  6) -.6 

indicates  the  Euclidean  algorithm  for  the  gcd  function.  Here,  the  possibilities  of  ambiguity  and 
the  burden  on  the  system  are  reduced,  but  the  user  himself  is  required  to  design  the  algorithm 
to  be  employed 

• Predicate-logic  language  This  is  a direct  descendent  of  the  theorem-proving  approach. 
The  specifications  for  the  program  are  expressed  as  resolution-style  clauses;  the  system  then 
transforms  these  clauses  into  another,  equivalent  set  of  clauses,  which  can  be  regarded  as  the 
desired  program.  (Sec,  e g.,  Kowalski  [1974],  Clark  and  Sickel  [1977],)  We  question  whether 
the  clause  form  has  the  notational  flexibility  to  serve  as  a suitable  specification  language;  for 
example,  many  of  the  constructs  we  use  in  our  specifications  would  not  usually  be  permitted  in 
a predicate-logic  clause 

• Synthesis  by  debugging  Human  programmers  produce  their  programs  by  the  successive 
debugging  of  nearly  correct  programs  It  has  been  proposed  that  a synthesis  system  could 
benefit  by  imitating  this  process.  In  this  way,  it  could  focus  its  attention  on  the  main  features 
of  a problem,  postponing  consideration  of  the  details  until  afterwards.  Such  techniques  have 
been  applied  to  the  construction  of  robot  plans  (Sussman  [1975])  and  electronic  circuits 
(Sussman  [1977]),  for  example,  but  not  to  the  solution  of  more  typical  programming  problems. 

• Synthesis  by  analogy  It  is  unusual  for  a programmer  to  construct  a program  from  its 
specifications  by  a purely  deductive  process,  normally,  he  attempts  to  apply  techniques  extracted 
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from  previous  solutions  to  similar  problems  Thus,  he  might  compute  the  square  root  of  a 
number  by  a binary-search  technique  extracted  from  a previous  program  to  divide  two 
numbers  Most  of  the  work  on  this  approach  (eg.,  Manna  and  Waldinger  [1975],  Dershowitz 
and  Manna  [1977],  and  Ulrich  and  Moll  [1977])  requires  that  a close  syntactic  correspondence 
be  found  between  the  specifications  for  the  two  programs;  this  correspondence  then  provides  a 
basis  for  transforming  the  previous  program  to  solve  the  new  problem.  To  be  more  effective, 
these  techniques  must  be  strengthened  to  take  advantage  of  looser  similarities. 

• Automatic  programming.  It  has  been  claimed  (eg.,  see  Balzer  [1972])  that,  for  a complex 
programming  task,  it  is  unrealistic  to  expect  the  user  to  formulate  complete,  correct 
specifications  for  the  desired  program.  In  specifying  an  airline-reservation  system,  an  operating 
system,  or  a spacecraft-guidance  system,  for  example,  we  are  unlikely  to  anticipate  the  desired 
behavior  of  the  system  in  every  possible  situation.  In  some  systems,  the  specifications  for  the 
program  are  formulated  gradually  through  an  extended  dialogue  between  the  user  and  the 
system.  (See,  e g..  Green  [1976],  Barstow  [1977],  Balzer  et  al.  [1977],  or  the  survey  of  Heidorn 
[1976].)  The  dialogue  is  continued  during  the  program-construction  process,  so  that  the  user 
can  resolve  any  ambiguities  or  inconsistencies  the  system  might  discover.  Typically,  these 
systems  attempt  to  play  the  role  of  an  expert  programmer-consultant,  and  they  tend  to  rely  more 
on  built-in  knowledge  than  on  deductive  processes.  By  admitting  natural  language  as  a 
communication  vehicle,  automatic-programming  systems  avoid  the  necessity  of  specifying 
programs  in  an  artificial  formalism;  however,  they  add  to  the  problem  of  program  construction 
the  not  inconsiderable  difficulties  of  natural-language  understanding. 


A survey  of  various  approaches  to  automatic  program  construction  can  be 
found  in  Biermann  [1976]. 


E.  Unsettled  Questions 

Many  of  the  techniques  we  have  presented  in  this  paper  bring  to  mind  questions  that  have 
not  been  adequately  answered  Some  of  these  are  mentioned  here. 

• Conditional-formation.  We  have  introduced  a case  analysis,  and  consequently  a conditional 
expression,  when  we  failed  In  an  attempt  to  prove  or  disprove  some  condition.  This  attempt, 
however,  may  be  somewhat  time-consuming,  as  It  involves  exhausting  all  the  rules  that  might 
apply  to  the  condition.  Moreover,  there  are  certain  situations  in  which  we  can  see  in  advance 
that  the  theorem-proving  effort  is  doomed  to  failure.  For  example.  If  we  can  find  a legitimate 
input  that  will  cause  the  condition  to  be  true,  and  another  that  will  cause  the  condition  to  be 
false.  It  IS  clear  that  we  can  neither  prove  nor  disprove  the  condition.  Is  is  possible  to  recognize 


90 


Loose  Ends 


some  of  these  situations  quickly,  thus  avoiding  the  expense  of  a pointless  theorem-proving 
effort? 

• Generalization.  We  formed  a generalized  procedure  when  we  discovered  that  two  subgoals 
were  an  instance  of  a "somewhat"  mere  general  expression  For  all  the  examples  in  this  paper, 
the  only  generalizations  we  require  involved  replacing  a constant  by  a variable,  or  replacing 
one  occurrence  of  a variable  by  a new  variable.  In  some  cases,  however,  it  is  necessary  to 
replace  a complex  term  by  a new  variable.  On  the  other  hand,  if  the  specifications  for  the  new 
procedure  are  too  general.  It  may  be  impossible  to  construct  a program  that  satisfies  them. 
What  limits  shall  we  set  on  the  extent  of  generalization  we  permit? 

• Termination.  In  forming  simple  recursive  programs,  it  is  always  possible  to  establish 
termination  by  finding  a well-founded  ordering  between  the  input  of  the  program  and  the 
arguments  to  its  recursive  calls.  Methods  for  finding  this  well-founded  ordering  during  the 
derivation  prixess  have  been  discovered  and  implemented  in  the  DEDALUS  system.  However, 
we  have  seen  that,  to  prove  the  termination  of  systems  of  mutually  recursive  procedures,  it  is 
necessary  to  find  termination  functions  that  map  all  the  inputs  and  arguments  into  a single 
well-founded  set.  How  are  we  to  find  these  termination  functions  and  the  related  well-founded 
set  during  ^he  synthesis  process? 

• List-manipulating  programs.  We  have  introduced  techniques  for  forming  programs  that 
manipulate  data  structures.  In  our  examples,  however,  the  only  data-structure  manipulation  we 
perform  is  the  assignment  of  values  to  variables.  The  same  techniques  can  be  applied  in  a 
straightforward  way  to  construct  array-manipulating  programs.  Can  these  techniques  be 
extended  to  develop  programs  that  change  the  structure  of  lists,  graphs,  and  other  complex  data 
objects?  The  in-place  list -reversing  program  and  the  Schorr-Waite  garbage  collection 
algorithm  are  programs  within  this  category 

• Simultaneous  goals.  The  techniques  we  develop  for  achieving  more  than  one  goal 
simultaneously  presuppose  that  the  transformation  rules  at  our  disposal  can  focus  on  only  one 
goal  at  a time,  so  that  the  various  goals  must  be  achieved,  and  protection  conditions  checked,  in 
separate  stages  Couldn’t  we  devise  transformation  rules  that,  while  trying  to  achieve  one 
condition,  consider  what  conditions  have  been  protected,  and  what  other  conditions  have  yet  to 
be  achieved’  Thus,  a rule  that  was  about  to  introduce  an  assignment  statement  Into  the 
program  might  check  whether  it  is  permitted  to  change  the  variable. 

• Stratagic  controla.  We  have  introduced  strategic  controls  to  prevent  the  derivation  tree 
from  growing  unmanageably.  In  the  derivation  trees  constructed  by  the  DEDALUS  system,  the 
unsuccessful  branches  at  least  represent  plausible  and  well-motivated  attempts  to  solve  the 
problem  Will  this  mechanism  still  be  adequate  when  we  increase  the  number  of  rules  from  one 
hundred  to  one  thousand,  or  the  size  of  the  target  program  from  a few  lines  to  a few  pages? 
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• Efficiency.  The  techniques  we  have  introduced  are  not  concerned  with  the  efficiency  of  the 
programs  they  produce.  However,  if  program-synthesis  methods  are  ever  to  become  practical, 
they  must  take  efficiency  considerations  into  account.  This  is  not  to  say  that  a synthesis  system 
will  need  to  perform  a mathematical  analysis  of  the  program  being  constructed;  It  would  suffice 
to  find  crude  estimates  of  the  running  time  to  guide  the  derivation  (cf.  Wegbreit  [I976],  Kant 
[1 977]). 

• Specifications.  The  only  specifications  we  have  allowed  describe  the  relationships  between 
the  expected  input  and  the  desired  output  of  the  program  to  be  constructed.  Such  "input- 
output  specifications"  are  inadequate  to  describe  certain  classes  of  programs.  In  particular,  in 
specifying,  say,  an  airline-reservation  system  or  an  operating  system,  which  are  never  intended 
to  terminate,  it  is  necessary  to  express  relationships  between  the  inputs  it  accepts  and  the 
outputs  it  produces  at  intermediate  stages  in  the  computation.  Can  the  techniques  we  have 
used  with  input-output  specifications  be  extended  to  allow  the  construction  of  such 
"continuously  operating  programs?" 
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